The failed million-dollar MVP

Explore the pitfalls of traditional executive-led product development versus a team-led approach with lessons from real-world experiences.

There is no single path to success in new product development, but it can feel like there is only one way (whether at a startup or a big company) — that of the founders or executives. For these teams, it can feel like a tightrope walk where any departure from leadership’s vision will lead to failure. Despite a desire to “fail fast, fail often,” most teams do not actually succeed in that aspiration, investing millions and wasting months or years. I’ve experienced both the traditional exec-led product development model and a team-led one. Each of these models has merits, but neither can guarantee product-market fit. I favor the team-led model because of the positive impact that it can have in uniting a team, encouraging them to stretch beyond their comfort zone and do their best work — where both company and personal growth goals align. There are some challenges to work through in either of these models that early startup teams (founders and a few members) should consider when evaluating the right approach for them.

Pressure

In the exec-led model of new product development, there is immense pressure on the founders or executives to convince team members of the validity of their vision. If a PM lead exists on the team, their job is to make the product that leadership has envisioned successful — the solution has been decided. This exerts enormous pressure on team members to buy in, despite misgivings, and to commit wholly to building out that vision. I’ve experienced both sides of this model. As a team member, I’ve participated in prolonged debates with leadership who seemed unmoved by the concerns raised by the team. Unable to change leadership’s mind and exhausted from frequent debates, the team reluctantly falls in line and builds out the vision despite lingering doubts.

Having acted as the product lead in startup and big company environments, I’ve felt the tremendous weight of trying to steer the team toward success — there was never much room for failure. Perceived stumbles resulted in decreased faith from jittery executives in other parts of the company who sought resources for their own teams. Failure meant the project's cancellation at a big company. At a startup, a shortened runway and the looming dissolution of the company.

There is a tremendous expectation to reach certainty as soon as possible and heavy discomfort with the inherent ambiguity of early-stage product development. This unspoken need from the team and external stakeholders (e.g. executives, board members, investors, founders) converge on the acting product lead, making it unwise for them to acknowledge doubt, even though it might be appropriate, leading to dissatisfaction for all involved. There is immense stress on everyone when the expectation is to succeed even though that’s typically not the outcome given how often new ventures fail.

I've also practiced a more iterative, team-led approach to new product development modeled after the design thinking process, as taught by the Stanford d.school and practiced by IDEO. In this user-centered, experiment-driven model, team members share ownership and the responsibility of finding product-market fit. There are discussions, but instead of lengthy debates, continuous user feedback on iterated prototypes settles many disagreements. This lightweight process allows team members to take comfort in the structure of how to go about discovering user needs and potential solutions. Failure doesn't have as much of an emotional punch because it is part of the learning process. The uncertainty decreases as the team iterates based on frequent user feedback. In one of my experiences, the prototype that showed the most promise did not come from leadership. Instead, two team members created it, riffing on each other's ideas. We still felt pressure to succeed, but it was a weight that we all shared. There was joint problem-solving and a shared sense of adventure — it was even fun. We were a team trying to figure out a way forward together rather than just a group of colleagues doing their jobs.

Time and money

In the traditional exec-led model, creating an MVP can take nine months to 1.5 years or more before leadership decides to continue investing or end the project. Without a clear positive result, the project will likely languish as the team works on other priorities. The company will have spent millions on unclear returns.

For example, a startup with eight members may spend a year building an MVP. The company conservatively spends ~$1.4M (assuming an average salary of $175k) on headcount alone. Similar teams at a big company would take even longer. All this means is higher sunk costs. If the effort is successful, then all is well, but it often is not. What the team learns in the process is lost when they are reassigned to other projects. What is certain is only that they failed.

In contrast, the team-led model encourages quicker experiments and iterations based on user feedback, so in 12 weeks, the team should be able to validate several hypotheses, discover where they might have been wrong, and adjust course. The team can build on their past findings — failures aren't bad because they're just learnings. If there isn’t a way forward — as in one of my experiences — then the call to stop happens earlier. The cost of these learnings in both time and money is significantly less than in the traditional product development model. If this approach has a potentially higher ROI, why do most teams follow the exec-led model?

Certainty, security, and clarity

Being a part of a team with a leader with a clear vision brings a sense of security. This top-down approach is reassuring because the product leaders know what they’re doing (at least, they project that confidence). Team members only need to worry about execution. Product managers take on more project management responsibilities rather than needing to figure out product-market fit. This command-control approach works well when there are strong signals for product-market fit. However, the certainty and security might be short-lived if that is not true.

In the best-case scenario, the solution dictated by leadership finds product-market fit. The company grows and is successful for awhile. At some point, continuing with this top-down process may hinder scalability and innovation because executives become the bottleneck for decision-making. The business becomes vulnerable to stagnation and competitive threats. User growth and revenue can flatten or decline (e.g. Instant Pot), and smaller, faster-executing companies can overtake market share. To remain nimble, companies need to innovate. One such way is to train internal teams in new product development. Leadership can teach team members to make decisions and be okay with failing if it means learning. Seasoned leaders may find it hard to trust that the team can make good decisions (as good as they can) and cannot let go. The team may end up in this quasi-autonomous state where they make decisions but are then second-guessed, never having the autonomy to make mistakes. It is as much a learning experience for leadership to delegate as for team members to assume ownership and responsibility.

In the team-led model, team members who are not used to having so much autonomy, even if it is something that they desire, may become frustrated. Prior early-stage product development experience or expert guidance helps the team manage uncertainty and avoid becoming stalled. Those who are product-oriented and want to experience the impact of their efforts first-hand do their best work under this model.

When does that team-led model work?

There are a few scenarios where this team-led approach to product development shines:

1. An early-stage startup team consisting of founders and a few team members.

   Many people are attracted to joining startups because of the potential for impact and the opportunity to learn things that would not be available to them in a big company. Inviting them to fully participate in the process as thought partners makes the best use of their drive and energy, while the founders are still hands-on. If initial efforts aren't fruitful, the team will learn and will have learned to fail together, making them more effective in subsequent efforts. When the team is successful, the company will have multiple trusted team members capable of driving product development as the company scales.

2. A team in a growth-stage startup when the founders can no longer make day-to-day product decisions.

   This inflection point is a good time for the founders to select talented team members who can lead and train them to make decisions that jive with the original vision. Although the founders cannot be as actively involved as they had been in the early stages of the startup, they can still provide significant guidance in steering the team toward a desired goal. The team needs to experience the ups and downs of new product development and have the leeway to make and learn from their mistakes. This way, the founders can gain confidence that the team can make quick decisions and keep mistakes cheap.

3. An in-house team in a large company can be tasked to experiment and create potential new product lines.

   There are likely team members in the organization who yearn for the experience of creating new products but who may need more guided opportunities to learn. These team members are well-trained in their craft and just need coaching through the experimentation process. Given that the company has a stable, growing core product, such an investment would be worthwhile to mitigate the risk of stagnation.

New product development can mean creating entirely new products or adding new features to an existing product. Instead of getting caught up in lengthy and complex MVP phases, companies (regardless of size and stage) can prioritize short, iterative cycles with clear goals and hypotheses. Instead of doggedly building out a full-fledged MVP that may not yield desired results, the team will have three more cycles (assuming the average of a year-long cycle) to attempt to do so versus one cycle and a much longer runway.

There is no silver bullet to success in product development. Failures are disappointing, but we can alleviate their impact by learning concrete lessons about users and the market. When there is room to fail, there is more room for risk-taking and creativity and better chances for innovation. Startups shy away from having a process for new product development because of the connotation of bureaucracy and slowness, but the de facto exec-led process exists regardless. A lightweight process acknowledges and alleviates the anxiety of uncertainty and ambiguity. By changing the experience, leadership can approach new product development in a structured, user-centered manner that fully utilizes the potential and skills of the entire team, thus inspiring and energizing them in growing the business and their own professional and personal growth.