Subscribe
Sign in
What is one piece of advice you'd give to yourself a year ago in your product building journey?
Technical answers welcome - curious about how people may have developed their stack in a different way to avoid legacy code / headaches down the road.
10
Replies
Best
@michaelshoup This is a good one. Often we have aversion to negative feedback, but it's better than none at all.
Launching soon!
@michaelshoup have you ever launched a beta before a public launch. We worry that getting too much feedback that you can't implement on is worse than a lot of power users giving you more granular / practical insight.
@dzaitzow I have - often I'll do a private Alpha, then Public Beta to establish feature set and value pricing, then increase prices as we move out of Beta.
My thought is too much feedback is a better problem to have than no one knocking on the door.
Launching soon!
@michaelshoup yea I share that sentiment - but oftentimes the ones building the product have a different set of expectations for themselves / their vision - always a fun back and fourth!
Have a plan for distribution.
Codebase and fanbase should be developed in parallel.
I have two pieces:
1. focus on the M of MVP
Think deeply about what the minimal viable version needs to have and cut EVERYTHING ELSE. It's so easy to go from one feature to next one adding more and more stuff, when one should actually focus on getting the initial product out of the door and then validate whether it is worth pursuing.
2. don't sabotage your validation
You need to be brutally honest when validating your product / idea. That's not the time to sugarcoat results. There's no point in promising potential customers the world and giving them 90% discount codes, just to be able to say you have PMF. It will just skew your results and have you focus on the wrong things.
Launching soon!
@fscholz couldn't agree more - Feature creep is a terrifying thing that I think we're all victim to - If it only had x y z - it would be perfect...
Podcraftr