The genesis of metafolly
Our long sabbatical over the last couple of years allowed Deepa and I to reflect upon the product development workflow in a different light. It gave us an opportunity to ponder over what had worked for us and what had not. Along with that, working with other startup founders as investors and advisors allowed us to watch from close quarters how others build products.
We could start identifying common challenges across all these companies. We decided to dig deeper. We interviewed over 50 people who were involved with designing, managing, and building technology products. We limited our research to people at fast-paced, high-growth technology companies since that’s the space where we have deep domain understanding.
Here’s what we learned.
1. The Cycle of Death
Most startups build products that do not align with customers’ needs and desires. To say it in a different way.. Most startups do not get to achieve product-market fit. You can say you have a product-market fit when your users highly value your product, when they highly depend on your product.
Often times you mistake some initial traction for product-market fit. You get excited, you throw marketing dollars to grow. You raise more money, and you spend it on marketing and sales driven growth rather than product driven growth. You get caught in this vicious fundraising cycle, always raising money because you are always having to spend money to grow. If you don’t grow, you won’t be able to raise your next round. And since your product doesn’t have legs, you just have to keep throwing more and more marketing dollars at it.
Perfect recipe for failure, right? Absolutely. Of the 70% of the technology companies that fail, the number 1 reason for failure, noted in 42% of the cases, is that their product didn’t serve the market need. That’s 42% cases where teams placed wrong bets in building products that didn’t align with the customers’ needs and their desires. And what’s the number 2 reason for failure? Running out of cash. That’s running out of cash while getting stuck in that vicious fundraising cycle.
What a colossal waste of our collective resources.. our brain power, our time, our passion, and our money!
2. The Detached Engineer
The second observation and challenge is perhaps best explained with a true example. One of our recent interviews with the founder of a B2B company led to the story of an engineer who joined the company a year and a half ago as the startup’s 4th employee. During the course of the first year, he was everything that you would wish for from your senior engineer. So it became a cause for serious concern to see his performance drop dramatically over the last 6 months. He wasn’t that rockstar anymore. During the 1-on-1 with this engineer, the founder discovered that he wasn’t enjoying as much as he used to in the past. He felt that the work wasn’t challenging enough.
This was in a way strange because things were going pretty well with this company. After a successful launch, the company signed up early customers and their numbers were growing. The team too grew from 5 to 20 people in a year. Two product managers were hired. Processes were streamlined, chaos was contained. Roadmaps were created. Two-weeks sprints became the norm. But somewhere along the way, the engineer’s performance dropped. He couldn’t relate to the product. He felt disconnected from the product and the company. The company’s vision just became a statement for him.
Determined to uncover what went wrong, the founder dug deeper and reflected on the early days of the company when it was a 5 people team sitting in the same room. The engineer was getting exposed to the customer pain, their desires, as well as the business constraints. He could relate to the customer, he could empathise with the customer. He was sitting side by side with the founder and the designer, solving problems. It slowly became evident to the founder that what the engineer found challenging was not just executing solutions, but solving problems. And these days, he is simply handed over the solutions. He isn’t involved anymore with solving the problem and figuring out the solution. The sprint backlog is nothing but a list of solutions that he has to execute. The sense of ownership has disappeared, and with it, his passion too.
Honestly, this one hit me hard. It seemed so familiar to me… developers telling me that work didn’t excite them any more, that work wasn’t challenging any longer. What they were really trying to tell me was that they didn’t find it interesting to merely execute solutions, that they want the product team to stop drowning them with solutions, and instead present them the problems to solve. Like many others, I was guilty of obsessing over keeping the solutions pipeline full, guilty of rallying my team in simply getting things done even if those features, those solutions had zero resonance with the customers. Had I been smarter, I would have tried to engage my dev team so much more meaningfully.
Coming back to the story.. So the challenge that this enlightened founder is left with is how to get engineering involved with problem solving rather than just executing solutions. How can product managers, designers and engineers collaborate effectively at problem solving at scale?
We have been intrigued by these observations, by these problems. They are hard ones, but we are convinced that they are worthy to be solved. And this has been the genesis of metafolly.
I will walk you through our hypothesis in the next blog post.
