Ask HN: How do you generally build a product?

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?

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.

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.

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) :)

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.

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.

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

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).

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.

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

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).

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.

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

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.

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.

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%

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.

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

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.

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.

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.

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.

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.

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

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.