ASK-IH: How do you find balance between evolving your product vs sales?
Recently, http://coreskills.dev proved to be something that someone needs with the first-ever paying customer (100$ 🤩).
This sounds like a great beginning, however, I recently stumbled upon the following problem: I lost a very promising prospect after they tried the product motivating it that it lacked the features they needed (at least this is what they said 😅).
So, fellow IHs, how do YOU find balance between convincing someone that your product will address their needs vs advancing it with more features?
Best,
Anton. 🙌
I would spend 50% on marketing and talking to users. More is welcome!
Spending any time on features and development more than you should, will drag you down.
You will become too complex,
Complicated,
And will have a unclear value proposition.
This also does not mean "build everything your users want".
Be smart, group and filter what you hear.
Build/develop as little as possible.
Landing page is much better (IIRC).
Still think you need to add pricing information. Most people are going to bounce out with no pricing.
How many website visitors have you had? How many signups? How many paid users? What is the signup flow like?
Landing prospects online has barely been a prio for me atm. I've been solely focusing on the local market as presumably, it's a shorter feedback loop (find a prospect, make they try the product, sell, try again). So I can't really tell you how many visitors I've had.
As for sign-ups, a handful of startups, one company that has bought a subscription and a few more I'm in the negotiations with.
The sign-up flow goes like this:
Then:
How many sales have you gotten offline? What is the average price?
So you're offering a service but trying to make it a product?
What's stopping it from being a product right now?
When I get the final version, do I get something to score the code against myself, if I don't want you to review the candidate's solution?
How about thinking about it as customer layers and sales goals to prove assumptions?
We should get some # customer type X before moving to the next customer/feature layer...
This was my thinking too. However, would you mean that further feature development should completely freeze until there is enough customer type X that buys the current version?
It's your decision to make how round you want the wheel.
Or allocation of resources or however you want to frame it.
It's easy for a builder to keep building and ask why they aren't coming.
There might need to be some counter effort from just keeping on what you were doing and making sure all the business parts get working and not just the product.
The thing with startup like iteration is you are done once you have learned something meaningful about the product to market fit that you would base future work on.
Did you build with as assumption this MVP would be usable by someone? Have some value? And be able to monitise/willing to pay?
Did you learn something new from that process that's meaningful?
Like customer wanting more features or cheaper is like almost meaningless in my mind cause it's an automatic and always true claim.. (also can read the coffee guy post about chasing the wrong customer just cause the customer says maybe rather than no)
Something meaningful leads to either proving an assumption or breaking it, making you pivot to fix for that new understanding a new experiment/assumption.
Don't be an empty endless builder cause it's easy and relatively fun or just your normal profession.
Getting a first sale in the door even if it's minor could change a product to a business and that's like way better than another feature.
That might start it's own momentum..
This comment was deleted 6 years ago