The "build as little as you can get away with" advice makes sense, but how does one actually know when one has hit that minimum threshold?
What if one builds minimal, gets negative feedback, but adding just one feature (or improving the UI) would flip user perception from negative to positive? How does one distinguish between "validate more" and "we actually need this one thing"?
It seems like there's a real risk of under-building just as much as over-building, especially when user behavior doesn't always match what they tell you in interviews.
In theory, theory and practice are the same. In practice, they are not.
In theory, there may be as much risk of building not enough as building too much.
In practice, well, let's find examples of products where just a few more features would make/have made a difference. Seriously, I'll wait.
I could share an endless list of products where a long effort to continuously add features changed nothing. And it didn't save these products.
I could share an equally long list of products that were utter failures. The quicker they were abandoned, the lower the cost. For them, adding another feature wouldn't do anything either.
In practice, we err so far in the land of "building too much" that "build less" is a safe guidance. Even if we could theorize a case where it would be bad advice, I'm doubtful that it would be applicable to, well, just about anyone.
Sure, overbuilding is more common than underbuilding. Still, what signals should founders look for when they get negative feedback to distinguish between "this concept is fundamentally wrong" and "this needs one more piece to click"?
The meta-answer is traction. That's what we should look for. If what we're building is any good (as in: solves an actual problem for people), we should be able to validate it through traction.
We'd get the interest of people.
Maybe we'd find a raging fan, even.
People would keep using the product.
Sure, it won't be all roses from day one.
There will be churn, which means we're not there either in terms of Problem-Solution Fit or Product-Market Fit.
There might be customers from outside of the initial target, which could make the whole effort way more complicated (as in: which group do we primarily serve?)
We may have financial considerations, like whether the revenue curve would justify ongoing development.
Etc.
But ultimately, there will be traction. That's the first sign a founder should be looking for.
Take one of our clients as an example. Their offering targets sport organizations. So the most basic signal is: how many of these organizations:
a) start using the product?
b) keep using the product?
c) pay for the product (and how much)?
Plot these lines over time. You get the most rudimentary reading of their traction. The more it goes up, the more validation they get.
The "build as little as you can get away with" advice makes sense, but how does one actually know when one has hit that minimum threshold?
What if one builds minimal, gets negative feedback, but adding just one feature (or improving the UI) would flip user perception from negative to positive? How does one distinguish between "validate more" and "we actually need this one thing"?
It seems like there's a real risk of under-building just as much as over-building, especially when user behavior doesn't always match what they tell you in interviews.
In theory, theory and practice are the same. In practice, they are not.
In theory, there may be as much risk of building not enough as building too much.
In practice, well, let's find examples of products where just a few more features would make/have made a difference. Seriously, I'll wait.
I could share an endless list of products where a long effort to continuously add features changed nothing. And it didn't save these products.
I could share an equally long list of products that were utter failures. The quicker they were abandoned, the lower the cost. For them, adding another feature wouldn't do anything either.
In practice, we err so far in the land of "building too much" that "build less" is a safe guidance. Even if we could theorize a case where it would be bad advice, I'm doubtful that it would be applicable to, well, just about anyone.
Sure, overbuilding is more common than underbuilding. Still, what signals should founders look for when they get negative feedback to distinguish between "this concept is fundamentally wrong" and "this needs one more piece to click"?
It's never "one more piece to click" :D Some smart people wrote entire books around that observation: https://www.amazon.com/Escaping-Build-Trap-Effective-Management/dp/149197379X
The question is valid, though: what signals should we look for to understand whether the idea is not going to fly?
Again, some smart people wrote entire books around that question: https://www.amazon.com/Running-Lean-Iterate-Plan-Works/dp/1449305172
The meta-answer is traction. That's what we should look for. If what we're building is any good (as in: solves an actual problem for people), we should be able to validate it through traction.
We'd get the interest of people.
Maybe we'd find a raging fan, even.
People would keep using the product.
Sure, it won't be all roses from day one.
There will be churn, which means we're not there either in terms of Problem-Solution Fit or Product-Market Fit.
There might be customers from outside of the initial target, which could make the whole effort way more complicated (as in: which group do we primarily serve?)
We may have financial considerations, like whether the revenue curve would justify ongoing development.
Etc.
But ultimately, there will be traction. That's the first sign a founder should be looking for.
Take one of our clients as an example. Their offering targets sport organizations. So the most basic signal is: how many of these organizations:
a) start using the product?
b) keep using the product?
c) pay for the product (and how much)?
Plot these lines over time. You get the most rudimentary reading of their traction. The more it goes up, the more validation they get.