HACKER Q&A
📣 tr1ll10nb1ll

How do you generally build a product?


Okay, so, you've got ideas in your to-do list probably if you're anything like me.

I want to know how do you find the time to build that idea out and even during that process of building, do some of the good ideas get left out? Is it partially because you don't have the right kind of developers to work with? If you had your developers friends working with you, would you get more products built?

How do you tackle this problem generally and ultimately, what does the process ends up looking like when you turn that to-do list idea into a product?


  👤 nocommandline Accepted Answer ✓
1) First start with trying to sketch out (write out) the solution on paper. Writing out your solution forces you to think the problem through. Psychologically, you don't see it as being stressful or as tasking as writing code which means you're more likely to stick with it for some days.

2) Try to work on your idea at least 4 or 5 days of the week, no matter how small the time. You don't have to write code. Sometimes it could be something as small as choosing a color scheme, picking your twitter handle, registering a domain name. You just need to make progress.

3) Acknowledge upfront that this idea might not lead anywhere and might not be commercially viable but the knowledge gained is not lost and you can use that idea in something else. For example, I once worked on a pet project that involved turning SVGs into PNG or GIFs via Javascript. I also worked on another project where I tried to build a blogging platform on Google App Engine (I was trying to learn more about Flask and Google App Engine). Both did not go anywhere. However my latest project - https://nocommandline.com - uses the code/knowledge from those 2 projects. My blog is based on the blogging code and some of the images I use were generated from the other project. In fact I have used that in some other stuff I did for people


👤 terminalserver
Think of a product name. Buy the domain name. Launch a cloud linux server, install web server, database, application server. Configure it all up to talk to each other. Build the user creation and auth system. Implement email system for user emails. Start building the hardest bits of the application first, try to get a minimal end to end implementation of the system, iterate over the minimal version improving stuff until it’s holding together as a full application, tune, polish, do the deployment stuff.... domain name, google analytics, backups, open the firewall launch. Wonder how the fuck to get users, shut it down, build something else.

👤 nprateem
TBH I've created so many things over the years I've learnt my lesson. Now, I always start with a marketing plan:

* Who's your target market, and how big is it and what are they likely to pay?

* What do they want?

* How will you create value you can capture?

* How will you reach them?

* What's the competition?

If you can't answer these or don't get decent answers, bin it and move on. It's easy as an engineer to build stuff, but if you build it, they probably won't come, so you might as well work out whether you're wasting your time in advance instead of at the end.


👤 fbelzile
Work a little bit on the project every day. Consistency is key. Even if it just means developing for an hour or two after your day job. It sounds cliche, but 2 hours - 5 days a week for a year adds up to 520 hours you can build your product with. It's how my business got started.

Focus on building and releasing your minimum viable product as soon as possible. This will also help you gain some internal motivation. As soon as you have people using your product and start getting feedback, you'll feel that the project has a life of it's own and you'll just want to keep working on it more.

Have fun, and pick an idea that doesn't feel like work (too much) :)


👤 orangegreen
If I have a good enough idea for a project, I just kinda start making it. No plan. Just trial and error, trying to get what's in my head on to the screen.

This is generally an extremely inefficient way of making a project since planning is usually a good idea, but it's just the way I do things, so I've embraced just starting and seeing where it goes.

I work on projects every day after work for about 2 hours a night, and on weekends for about 4 hours a day. Many times I don't feel like working on my project but I'll still work on it anyways. Nothing better to do.

I always try to make the absolute simplest product I can get away with as I have lots of things I want to make, and after months and months of working on a project I get bored. But... I make sure to always finish what I start.


👤 0xbadcafebee
I wouldn't tackle it generally. A lot of products are like building a house. You don't generally build a house. It's a very specific thing that encompasses many different fields of expertise. You can build a house and sell it by yourself, of course. But nobody here is going to be able to tell you how in a single forum comment.

Suffice to say you need to learn to become a developer, a project manager, a product owner, an architect, a systems engineer, a customer support specialist, a salesman, a marketer, a financial officer, and an executive officer. If you are good at learning on your feet, you will learn just enough of these things to get your product running and make some money, from a month to a year or more. It all depends.


👤 sawyer
Scratch your own itch. Solving a problem you have will motivate you, but more importantly it’s the only way to be able to navigate through a problem space.

Without being the customer you will have so much trouble coming up with solutions to problems people are willing to pay to solve.


👤 kureikain
To build a product, I look to see if I can get something out in a 2 week so I can at least dogfooding it. The purpose is I should be able to use it daily asap to keep my momentum and solve my own pain point. Without seeing the pain, I'll easily lost motivation and give up. I also try to pick a product idea that emphasize my strong skill and less depend on my weak spot.

A case study, for my email forwarding app https://hanami.run

1. Create a PoC without any UI. As in, backend only, no database, just JSON so I can configure it. the app boot, load data from that JSON file. If I need to change anything, I edit that JSON file, The app reload it.

2. It works. Awesome. The core of business work. It's useful to my daily work. I can hook up domain to it and forward email

3. Started to get on front-end. Get a few friend, ask for their feedback. Setup a weekly sync with them. This is important. It forced to make progress

4. Get a google docs for what I should ship and what I achieve that week.

5. Continue use it daily. See pain point. Keep improving. Example, I never though I'll log email. But eventually I added that features and people love it. I never though I'll need an API for email forwarding but turn out many users want ability to curl and get email in JSON format

As you can see, my product is heavily depended on my pain point. Without me having a need to use that product myself, I think it's hard to build.

So my process is always to look for what I wish should existed and go do it, weekly sync, have a few friends to give you feedback/beta tester every week, congratulate small wins.


👤 ronyfadel
I’m a full time indie hacker, building my own products (several in the pipeline) and doing my own design and marketing as well.

Regarding the product idea, it varies from an itch I have, to a neat idea but I’m not the target audience, so I ask around (esp. on Reddit), to someone asking me to make them something and I ask if instead of billing my hourly rate, I can sell them a productized service. I jot down my “itch I have” ideas regularly in a to-do app.

I’ve tried building the product without designing it first (jumping straight to code) and I’ve found that it has always been a mess (re-designing multiple times in code).

I now design the concept first (in Sketch) and only once it feels right, I get implementing. I create a basic styleguide and reusable symbols, which I reuse throughout the app/product.

Then I get implementing. Once I have something that starts to work, I tease it out on Twitter/Reddit and see if people like it. If it gains steam, it gives me enough wind under my wings to continue developing it.

I give myself X amount of time to ship (otherwise the project takes forever).

Once “done”, I send it to a few friends using TestFlight/MS AppCenter for beta testing.

If all goes well I prepare a launch page and launch on ProductHunt.

Depending on the niche I communicate with bloggers on launch day (a big chunk of my buyers are referred from these blogs even years later).

Regarding time and idea picking:

I just do what I’m psyched about, whenever I want. I’m lucky to have financial security at the moment.

What I wish I had in a partner:

Someone who can complement my skills: someone better at design who can still develop.

I’ve already talked with dev acquaintances about teaming up for weekend projects. Would definitely be fun and I don’t care as much about getting 100% of the pie.

The to-do list:

I put almost everything in a to-do, but only check it towards the last 20% of the project. I tag everything as e.g. Design, Client, Server, Marketing. Once the MVP “feels” done, I go through the list to see what’s missing.


👤 hutch120
My 2 cents... generally a product is something that has value to others... so, think about that first. Why is your product valuable to others? Explain your product to at least one person who is not invested in the process that would buy your product if it existed. Ask them lots of questions about why they would buy your product. Would their friends buy your product? Why? Can you pre-sell your product before you even start building it? You get the idea... sell first, build after. Sell a little, build a little, repeat.

👤 halfmatthalfcat
I start by just getting something to “work” and it usually is completely unoptimized and looks like shit.

Once I’ve proven, technically it works, its a slow iterative process of turning coal into a diamond.

Sometimes that process takes days, sometimes weeks and for me specifically, years. But it’s the drive to finish that actually gets you to a completed project. Drive and conviction that your thing is going to fulfill your goals (whether that’s money, scale, technical accomplishment, experimentation, etc).


👤 weswpg
It sounds like everything you mentioned falls under the heading of software project planning. Are you familiar with those techniques already and possibly asking whether those should be applied to personal side projects?

👤 invaliduser
Do you mean software or product ? At the time of this writing, all answers are about writing software, but a product implies a market, and most of the process is about what problem you are trying to solve for a customer, and evaluating the value provided. The software development usually starts when there is enough knowledge to sketch an MVP.

👤 uxle3
How do you eat an elephant? ... one small bite at a time.

I'm a visual person, so first I map it out -- sections, pages, functions, classes -- whatever is appropriate.

Then after figuring out what needs to happen -- the process of visually laying out everything I can think of (mindmapping tools, paper & crayons, etc)

Try to come up with some type of estimate of how long it will take for each step, smaller the pieces are the better! (essentially, storypointing like in standard project management situations)

Then, I schedule it into my life: 15mins here, an hour there, a weekend sprint, etc

This really helps to see how long stuff might take, or will take. Update the estimations and map frequently. I schedule this too - like a weekly check-in with myself for the project(s).


👤 Morje
For me, part of it is establishing MVP. Software can always be improved, that's why companies still have massive development arms years after launch.

Establish the minimum features for your product, build it, then talk to your customers to find out what they want improved.


👤 smackeyacky
This was the process we went through to build a hardware and software product based around a bluetooth LE chip:

1. Get hold of a development board (say an nRF52 or a Ti SensorTag). Get the dev system set up and get sample firmware running.

2. Build the MVP firmware. Doesn't have to be perfect just has to be enough to demonstrate the idea.

2. At the same time, build the surrounding software (phone app, services). Phone app use the closest thing you are comfortable with but Android development is a lot cheaper and testing your prototypes is easier as every Android device can be a developer device without paying the Apple bullsh*t taxes and jumping through all their hoops.

3. Dev account on AWS, use the free tier services (although be very careful about keeping an eye on costs).

Your MVP can't get far from the desk but it can be shown to people. In my case the product couldn't be tested without at least 20 devices mocked up but we simulated that with a pile of cheap key finders from alibaba. Get creative about simulating whatever environment you might be deploying to whether it's software or hardware or a combination. It makes the demos more believable.

4. Shop it around, get creative about who might be interested in helping you.

Unfortunately, the number of people who have ideas and can build them by themselves is surprisingly small. You'll need help but be careful about getting into business with people you don't know. I made that mistake and it cost me 2 years.


👤 alexbouchard
For me, the real trick is to boil it down to small milestones. Looking too big and too wide at the start of a product makes it feels overwhelming. Your mind (or at least mine) needs practical goals. Create a list of small goals that, when completed in aggregate, achieves your bigger vision. In many ways, vision is about thinking big, but the key to execution is to think in smaller chunks.

👤 irjustin
> how do you find the time to build that idea out

Based on this, I'm assuming you want to build an idea that makes money first.

You need to solve a problem that's worth paying for. Easily said, of course.

The Mom Test[0] is a book about how to ask questions that are worth pursuing as a business.

> do some of the good ideas get left out?

That's the question really to focus on. Don't worry about developers or building yet - the first question to ask is - is there really a problem here?

The first step really is about a basic litmus test. What's the cheapest way to "test" the idea without a costly build? End user research, landing page with some targeted traffic,

All about getting to a few potential customers who will give you feedback.

After that, then I say start building.

If you build in a vacuum (you and some developers), you're likely to get it very wrong.

[0] https://www.amazon.com/Mom-Test-customers-business-everyone-...


👤 ishwarjha
The better you have processed your idea, it significantly improves your chances of success. Before you take a plunge, add an intense and disciplined approach to brainstorm your idea and it's evaluation process:

1. Build lists of potential customer types, business and pricing models.

2. Evaluate the opportunities where these lists overlap.

3. Then, go out of your building and evaluate the top ideas with real potential users, customers, and suppliers.

4. The goal of evaluation process should be to know whether your idea has likelihood of success. Also, it will help you know early on to waste less time down the road, even if you pivot from your original idea.

I wrote a complete set of 11 articles to go from idea to launch and growth. Check it out here:

https://appetals.com/the-ultimate-guide-to-digital-product-l...


👤 whateveracct
I write it in Haskell and the breakdown of problem-solving is 10% coding and 90% subconscious thoughts while doing the dishes.

👤 chris_j
It would be helpful to give some ideas of the sorts of projects that you're thinking of. It sounds like you have a very specific idea in mind. What sort of things do you have on your TODO list and what are you assuming that folks here have on their TODO lists?

For me, the first thing when starting a project is to figure out who you're building it for and what problem you're solving for them. Try to talk to them and ask lots of questions about the problem domain and about their problem. Allow yourself to be surprised by the answers. This may involve learning to ask open questions and not coming into it with too many preconceptions. Try not to ask questions that assume what you already _think_ you know.

Secondly, try to build something (minimal) as quickly as you can and try to get someone using it. If you are lucky enough to have customers then great, either observe them using it or ask them how well it works for them.

Thirdly, try to iterate as quickly as possible. Whatever you build in the first place probably won't be the right thing anyway so try to learn, as quickly as possible, what is wrong with it, and then change it. Again, allow yourself to be surprised by what you learn and try to be aware of any initial assumptions that you might have, so that they don't lead you in the wrong direction if they turn out to be wrong.

All of the above assumes that you're lucky enough to have customers. If you don't have any then either abandon what you're working on or be content to work on something that scratches your own itch (in which case, you're the customer and you're the one who decides what works and what doesn't).

Finally, I'm still really curious about this TODO list with ideas that you might have. For me, nothing crushes my sense of intrinsic motivation more than feeling forced to pick up items from a TODO list. How does your TODO list work for you? What benefits does your TODO list give you? And are you aware of any negatives that spring from it?


👤 ilaksh
For me, I carefully structure my life so that I have time for a few ideas.

Not many ideas really. Usually its one or two. Maybe for a few months, years or several years.

And then I build them because I am a programmer.

The other option, for people who have money, is to create an inspiring vision, a mission, and a useful plan for accomplishing it. The use your large wallet to hire the best people you possibly can who really align with your mission. Make sure they stick to the vision and the plan. Re-iterate it if they deviate. Fire them if they really insist on going off in a different direction or if they don't perform. But at the same time, you need to be able to recognize when parts of the plan need to be updated. To avoid having to do that too often, its best to hire extremely talented people to maintain the lower-level plans.


👤 practicalpants
I'd recommend starting out with a landing page first before you build the app. Like a really nice, well-designed one, that captures your vision and core points. Just copy some startup landing page you like and tweak it. Create from scratch or use webpage builder.

Gives you advantages: something you can share with others, a developed/implemented vision, something you can actually launch at any time without the underlying product for testing reasons, and something that will psychologically motivate you.

I used to build out backends first because it was easier for me, but many projects just didn't get launched. The landing page first is actually harder in my opinion, but psychologically having something presentable makes the project feel real.


👤 andrea_sdl
Ok, so, as both a developer and owner of a company that built a physical product (in the Cosmetic field, so no tech stack :D ) I'd say that, at least for me it all starts with scratching my own itch.

Create it for you, solve your problems, chances are you are among a group of people that share the same issues and the work will be "where do this people group together?"

Creating a company in a cosmetic field was challenging, but I do believe it's something feasable for everyone as long as you accept the fact that you must delegate part of the work.

I still think that this might be true for the dev field, so yeah, as many other pointed out: Build a decent MVP that solve a problem, share it with the people who care.

Obviously, for me, turning into a product means "making some money", otherwise you're simply testing. So, the process to get from "I have an idea" to "I have a product" might vary a lot.

I started saying "Scratch your own itch" because if you are not solving something you care about and you are infatuated by an idea, doing the market research, finding what the ideal customer really wants is hard. Instead, if you are the first customer of your product and use it daily it's much easier to find pitfalls, problems, defects and so on.

From there, a good advice I always found is trying to sell it to the circle of people you know even before selling online. If none of them buy the product (note the word "Buy". don't give it away for free) there's a good chance something is off. Yes, they might not be your target user, but I would bet that you should at least have a friend that shares part of your interests.

As for how to choose ideas: We have limited time, so I invest in the one with the higher probability of success and leave the others in a list. What happens is that, from time to time (rarely but not so much), I'll see someone else came up and made money with a similar idea. I'll bite my finger, smile, and move on :D Afterall what counts is not the idea alone, it's the execution. That will -always- make the difference.


👤 rvn1045
I’m a solo SaaS founder and I’ve built and released several products.

I would say just work on one complex product from start to finish. Do this however you can and after that everything will just get easier.


👤 fouc
Watch out for feature creep! Good ideas are a trap!

👤 monkeydust
Wanted to emphasise the value component.

If your building a product to sell (versus something for personal use) then you should try to quantify the value someone will get out of it (not always easy) - but - if you can model this then that helps with your strategy for pricing.

Put simply - if client gets $X value from the product you should be able to capture % of $X.


👤 stevage
I usually let it churn around my head for quite a long time before I do anything about it. Then, suddenly I'm inspired, and code like a mofo for a few hours. Then either it's good and I launch it to the world, or it's crap, and I quietly file it under "let us never speak of this again" and move on.

👤 saddington
i've been building software as an engineer for 20+ years for big cos and indie projects.

... they all kinda start out the same:

![](https://yen.fm/wp-content/uploads/2021/05/3-steps-for-basic-...)

i essentially boil it down to 3 steps:

1. Customer sends you data… 2. You manipulate the data… 3. You send the data back to the customer…

this is how i start the process... i figure out the fundamentals.

a few examples:

Dating / Matching Service: - You send me your dating preferences (via form)… - I’ll manually sort / categorize / match you with the “best fit” (manipulating data)… - I’ll send you your match (and you’ll pay me)! Customer gets a potential match and you get paid.

Collecting, Delivering Daily Standup Notes: - You (team) sends me daily standup notes (via web form)… - I’ll auto-magically categorize notes into business unit (ops, dev, design, legal, marketing, etc)… - I’ll send you (the team) all the notes related to your specific business unit! Individuals and teams are updated, aligned, and they now have the necessary info to do their job well.

Blogging Publishing Template: - You create a simple form to capture blog post ideas… - I’ll sort it based on length and other metadata… - I’ll send you the template to use for your post (with API access?)! Customer get a “best practice” blogging template and you get a repeat customer (monetization)?

... so, that gets me a baseline of the problem, the customer, and a very basic product... this can oftentimes done with #nocode or with existing services... you can almost fake a lot of this in the beginning.

if you've got the customer and the value right... then you can iterate on the product, part #2 which was once a manual (or semi-manual process) and then you graduate or iterate or evolve or level-up the product to be more automated over time.

this is a land-war of sorts... and will take many attempts to get it right. don't give up.

ping me if you need anything: john [at] yen [dot] io


👤 yewenjie
Is there a streamlined checklist or skeleton for planning various parts (backend, frontend, etc.) of a project?

👤 thinkloop
How do you find time to work on stuff that's not your awesome ideas? I have the same issue but for taxes.

👤 collin128
Not sure this is exactly what you're looking for (non-dev here) but I had a chance to interview Michel Feaster (HP/acquired Opsware/mentored by Ben Horowitz/founded Usermind) and picked her brain on how to create something.

The conversation centered around how to create a category but I think the process applies to side projects as well.

Copy/paste from Google doc didn't work well on mobile so here's a link to the doc: https://docs.google.com/document/d/1F0ex-c-vmitYQiDnSSODUZCW...

Michel’s playbook

Look for 3 big shifts in the buyer’s world

Conduct day in the life interviews

Asking When you walk in in the morning, what is the first thing you do every day? How many applications do you log into? What applications do you love and why? If there was a problem I could solve for you, what would it be and why? Who do you report to What are you MBOs

Looking for

What did they do all day What did they love What did they perceive as pain What were they promoted for if they did well What are their challenges in their interactions with their boss

Make sure you understand

Technology landscape Daily work life Responsibilities / mission

Look for patterns in the data

Common pains / problems Value attached to solving it

Find a gap you can solve

What’s the value to the user? What’s the impact on the organization? What’s the ROI of the impact? Value of solving?

Market

Start with a bottoms up TAM

How much do I think they’ll pay me for this? Shoot for 10% of the value, eventually. If I achieve 20% share of the market, is it a $1 billion company?

Then do a top down TAM

If I could redirect 1% of category spending, what would that be? $100b TAM = great for B2B, $1t for B2C?

Product

Break down what you’re going to build

Is it defensible enough from the way our competitors are currently doing things? Is there mental space for a new Kleenex? Whiteboard the solution

Identify 3 core capabilities you must build

See what’s out there for each of these How difficult is it to build each? How defensible is it?

Time horizon

Is anyone out there doing anything close to this?

Positioning / differentiated narrative

Can you define the narrative? How difficult is it to copy? How different is the platform? Can you get your competitors to sell on your narrative? Ex. No Software, Inbound Marketing, Conversational Marketing

Value

Early days you’ll only get 1% of the value you create As you grow, you’ll have more leverage and will be able to slowly bring that up to 10%