Ask HN: How do you generally build a product?
72 comments
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.
* 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.
What your target market wants is not that easy to determine. I've heard the book "The Mom Test" is a good read to help with this. I've started reading it recently.
I've tried it as well, it does seem to work as a good indicator to validate that you're going in the right direction initially. But like any good finding, needs a large sample size, so I decided to talk to more people about the same product I'm building.
Now, I'm thinking of a way to help others (users on my platform) do the same with their products without those surveys, people don't usually fill out surveys and are more receptive to conversations from my experience. Guess, I'll figure something out eventually.
Now, I'm thinking of a way to help others (users on my platform) do the same with their products without those surveys, people don't usually fill out surveys and are more receptive to conversations from my experience. Guess, I'll figure something out eventually.
People never know what they want untill it's shown to them, show it to them and they want it.
That's the plan Steve jobs followed and his company is still succeeding.
Same except I don't bin it, I put it in the "projects for fun" box.
NB: "What's the competition" is a very hard question when you're trying to innovate.
NB: "What's the competition" is a very hard question when you're trying to innovate.
There are generally three reasons for not having competitors:
1. You're blind to what you're competing against. 2. It's not a problem worth solving. 3. You're genuinely innovating, creating a whole new category, which you're the first to ever think of.
Number 1 and 2 are extremely common. 3 is extremely rare.
1. You're blind to what you're competing against. 2. It's not a problem worth solving. 3. You're genuinely innovating, creating a whole new category, which you're the first to ever think of.
Number 1 and 2 are extremely common. 3 is extremely rare.
This is exactly why it's a hard question to answer.
Innovation is not always "new problems to solve", but more often "new clever ways to solve a problem", which rules out number 2 IMHO.
For example, Kubernetes was an innovation in the cluster management field where many had already solved that problem with other means, and many still do today.
When you're trying to innovate, it's easy to fall in number 1 (being blind to the competition: current means to solve the problem).
Innovation is not always "new problems to solve", but more often "new clever ways to solve a problem", which rules out number 2 IMHO.
For example, Kubernetes was an innovation in the cluster management field where many had already solved that problem with other means, and many still do today.
When you're trying to innovate, it's easy to fall in number 1 (being blind to the competition: current means to solve the problem).
i've been building software as an engineer for 20+ years for big cos and indie projects.
... they all kinda start out the same:
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
... they all kinda start out the same:
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
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?
Where could I go for resources on that?
To some extent, yes, my question is about how "other" people plan their ideas and projects. I'm familiar with those techniques but I would like to know how others' timeline from an idea to a product looks like. When do they start getting other developers to work with them, how easy it is for them to convince others, etc.
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.
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.
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) :)
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) :)
Find a problem you'd like to spend 10 years solving.
The minimum viable product is 50% smaller (if not 90% smaller) than you assume.
Time getting feedback from potential customers is more valuable than time coding.
The minimum viable product is 50% smaller (if not 90% smaller) than you assume.
Time getting feedback from potential customers is more valuable than time coding.
Huh, I'm the complete opposite. Working in dribs and drabs like that gets me down, and consumes a lot of brainspace.
I'd rather wait till I have a whole day or weekend to devote to it, and go very very hard.
I'd rather wait till I have a whole day or weekend to devote to it, and go very very hard.
Problem is, those days tend to be far far apart. From one to the next, you'll have forgotten everything, and once saturday morning comes along, chances are the threshold to start again with that thing you last touched 5 weeks ago is so high that you end up bindge watching netflix instead.
Key is to keep the threshold minimal for getting back and making progress.
Key is to keep the threshold minimal for getting back and making progress.
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.
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.
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).
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
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
On top of this, pick a technology you already know, and start building.
Write about what you're building.
As an example, here's a thread of what I'm currently working on:
https://twitter.com/RozenMD/status/1364881512500404224?s=20
Write about what you're building.
As an example, here's a thread of what I'm currently working on:
https://twitter.com/RozenMD/status/1364881512500404224?s=20
Interesting that you mentioned about writing what you're building, there's something I found recently that helps with this https://www.buildinpublic.xyz. I'll be trying this strategy out for getting the word out.
To add to this: I often create small side projects that are at least useful to myself. I think I never created a project where I didn't re-use at least one piece of code in a later project.
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'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.
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.
Amazon uses this exact strategy. They write the press release first, then work backwards to design the product.
https://medium.com/intrico-io/strategy-tool-amazons-pr-faq-7...
https://medium.com/intrico-io/strategy-tool-amazons-pr-faq-7...
Honestly, this sounds terrible. If there is something the software world does not need then it's landing pages for vaporware.
I write it in Haskell and the breakdown of problem-solving is 10% coding and 90% subconscious thoughts while doing the dishes.
The sub-conscious thoughts float away for me whenever I sit at my desk again so I've decided to take, this is corny, but I just take voice notes or any kind of notes, no matter how small the thoughts on my idea are. I later review those notes, write the best ones down in ClickUp/Notion and well, make a feature timeline for them.
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.
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 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%
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.
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.
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.
I love this process, especially the design portion. A long time ago, I read Sketching With CSS, and I think it took me down a bad path. Lately, I’ve been creating designs for my apps in Figma before writing any code. It’s definitely, as you mentioned, saved me a ton of time on accidental redesigns. I just bought RefactoringUI by the guys who did Tailwind, and it’s great. Highly recommend it.
https://www.refactoringui.com/book
https://www.refactoringui.com/book
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.
I've never fully committed and built a solo product, so take what I say with a large pinch of salt, but from what I understand asking your friends "would you buy this" is supposedly a notoriously poor metric for market fit. Their answer is always going to be "of course!" because it's easy and it seems supportive, but the difference between "would I spend this hypothetical money on this hypothetical product" Vs spending real money is huge.
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.
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?
Skeletons and frameworks should be avoided at all costs.
Frameworks are sometimes useful if you know one well but if you're new to it its gonna be a huge time sink.
Skeletons are similar issue to frameworks, they give you a whole lot of boiler plate and distract you from solving the problem tying you up with the authors picky conventions.
The best framework is a .PHP file running on Apache.
Frameworks are sometimes useful if you know one well but if you're new to it its gonna be a huge time sink.
Skeletons are similar issue to frameworks, they give you a whole lot of boiler plate and distract you from solving the problem tying you up with the authors picky conventions.
The best framework is a .PHP file running on Apache.
I would like to nuance your statement a little bit. I agree that learning a new framework alongside building your project is a bad idea. But if there is a framework that you know well and it fits the project then definitely use it.
I have my standard stack of backend/frontend/database/infra tools that I know inside out and fit most web projects. So whenever I have a new project idea it takes me 20 minutes to get hello world from frontend through backend to db and back. And then I can start building using the FE/BE frameworks I already know.
Edit: I now see you mentioned this in the second paragraph so my comment is redundant.
I have my standard stack of backend/frontend/database/infra tools that I know inside out and fit most web projects. So whenever I have a new project idea it takes me 20 minutes to get hello world from frontend through backend to db and back. And then I can start building using the FE/BE frameworks I already know.
Edit: I now see you mentioned this in the second paragraph so my comment is redundant.
You are right about frameworks taking a lot of time and stall your idea if you aren't already good at one. However, if you are alright with not being to able to build your idea right then and there and are willing to extend the timeline by a few weeks, you might learn something new for ideas later. Last year, it took me 8 weeks to build something that could've been done in 4 weeks max but I'm glad I did that because I learnt Django quite well and now I'm using it to build my other ideas.
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.
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.
I always start with the fantasy that I can get an application built in two weeks.
That's how long it takes to get the MVP out there but coupling for procrastination, it takes longer than 2 weeks to get it out even though the actual work for the MVP does get done within two weeks.
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.
I agree. Acquiring users is harder than building the product. I have done this many times.
That's what I've been doing, not even kidding, and I'm not so sure this is the right strategy because this has got me to abandon some nice ideas.
You can just skip all this: create a landing page with a “Coming Soon” mock-up and sign up form.
Buy some ads, tweet and then wait to see if it’s worth working on.
Buy some ads, tweet and then wait to see if it’s worth working on.
[deleted]
This :) Basically start from the end of this submission and you will get there in no time...
> 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-...
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-...
You made a valid point about building in vacuum, that's exactly what I was doing with one of my projects last year and was wondering why I couldn't get any users who were sticking around. Sometimes, it can be the painfully bad UI but when that's not an issue either, you know, it's probably the problem you picked to work on itself.
So I'm assuming, before working on anything that you think might make some money or be useful to others, there always has to be some form of idea validation.
Nevertheless, what about the developers who don't have extensive developer networks nor the budget ( think : high school student or a 30 year old who can't convince colleagues to just quit their jobs and start working full-time with them ) but great ideas, which let's assume pass the Mom test. What do they do to get the word out for developers to start working with them, after all?
So I'm assuming, before working on anything that you think might make some money or be useful to others, there always has to be some form of idea validation.
Nevertheless, what about the developers who don't have extensive developer networks nor the budget ( think : high school student or a 30 year old who can't convince colleagues to just quit their jobs and start working full-time with them ) but great ideas, which let's assume pass the Mom test. What do they do to get the word out for developers to start working with them, after all?
Glad you realized and moved on. It's easy to continue and stay stuck in the vacuum with the tunnel vision and all. Just one more feature.
> What do they do to get the word out for developers to start working with them, after all?
A very different problem, but this co-founder dating.
It's hard because for people who don't have extensive networks, you're basically asking people to... build a network.
But if you can take an idea far enough with an MVP, get some sales, customers, it's significantly easier to convince a potential co founder.
Chicken egg problem made only worse, I know - but sadly, no easy answers here.
> What do they do to get the word out for developers to start working with them, after all?
A very different problem, but this co-founder dating.
It's hard because for people who don't have extensive networks, you're basically asking people to... build a network.
But if you can take an idea far enough with an MVP, get some sales, customers, it's significantly easier to convince a potential co founder.
Chicken egg problem made only worse, I know - but sadly, no easy answers here.
[deleted]
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.
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.
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?
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?
Alright, I'll help you understand what I'm trying to imply with the TODO list of ideas. It's fairly close to what you mean by intrinsic motivation to work on something. Except, sometimes, I, get different ideas to build something fun when I'm already busy with something I thought of as cool a while back.
For example, right now, I'm working on something full-time on what I thought would be really cool to build in January but along the way, I thought of other things as well, some of those require more time than just a weekend. I tend to write those ideas down instead of passing on them or getting involved in them and abandoning my current projects.
Keep doing this for long enough and you'll end up with a long list of ideas over a period of time so that's what I was referring to with the TODO list of ideas, ideas that really intrigue me, stuff I want to build but currently don't have the time for. I'm assuming this happens to other developers as well, at least, some of my friends do this. We even have a shared list of what we want to build together.
For example, right now, I'm working on something full-time on what I thought would be really cool to build in January but along the way, I thought of other things as well, some of those require more time than just a weekend. I tend to write those ideas down instead of passing on them or getting involved in them and abandoning my current projects.
Keep doing this for long enough and you'll end up with a long list of ideas over a period of time so that's what I was referring to with the TODO list of ideas, ideas that really intrigue me, stuff I want to build but currently don't have the time for. I'm assuming this happens to other developers as well, at least, some of my friends do this. We even have a shared list of what we want to build together.
Cool thanks for expanding. That TODO list of ideas makes sense now. Am I correct in understanding that finding the time/energy to actually do something with your ideas is the limiting factor for you? Or is it something else?
Yeah, you're correct with that observation.
I probably shouldn't be surprised to hear that because my experiences are similar and I understand that this is the case for most people.
My advice would be to work on projects that you are intrinsically motivated to work on. Don't work on a project in expectation of any reward if you complete it. Let yourself know that it's ok if you don't achieve all (or any) of what you might have set out to achieve in the first place. Myself, the side projects where I've achieved the most have been ones that give me a dopamine hit (basically games or things that are graphical, in my case, even though I've rarely been paid to work on those sorts of things in my career as a software engineer).
If you're interested in reading up on motivation then there are few books that I've found really useful:
- Drive by Daniel Pink talks about the different types of motivation (intrinsic vs extrinsic) and talks about the motivating factors of autonomy, mastery and purpose. There's a nice sketchnote video based on a talk by the author that did the rounds a few years ago https://www.youtube.com/watch?v=KgGhSOAtAyQ that sums up the key points.
- The Power of Habit by Charles Duhigg talks about habits, how they form and how you can understand and hack them.
- The Power Of Full Engagement by Jim Loehr and Tony Schwartz talks about managing different aspects of your life in order to have energy to do the things that are important to you.
Hopefully the above may be of some use to you. They have been very useful for me, particularly in understanding how counterintuitive human psychology is in some cases and in terms of understanding how some strategies that you may be tempted to use can be counterproductive.
My advice would be to work on projects that you are intrinsically motivated to work on. Don't work on a project in expectation of any reward if you complete it. Let yourself know that it's ok if you don't achieve all (or any) of what you might have set out to achieve in the first place. Myself, the side projects where I've achieved the most have been ones that give me a dopamine hit (basically games or things that are graphical, in my case, even though I've rarely been paid to work on those sorts of things in my career as a software engineer).
If you're interested in reading up on motivation then there are few books that I've found really useful:
- Drive by Daniel Pink talks about the different types of motivation (intrinsic vs extrinsic) and talks about the motivating factors of autonomy, mastery and purpose. There's a nice sketchnote video based on a talk by the author that did the rounds a few years ago https://www.youtube.com/watch?v=KgGhSOAtAyQ that sums up the key points.
- The Power of Habit by Charles Duhigg talks about habits, how they form and how you can understand and hack them.
- The Power Of Full Engagement by Jim Loehr and Tony Schwartz talks about managing different aspects of your life in order to have energy to do the things that are important to you.
Hopefully the above may be of some use to you. They have been very useful for me, particularly in understanding how counterintuitive human psychology is in some cases and in terms of understanding how some strategies that you may be tempted to use can be counterproductive.
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...
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...
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?