The Rabbit R1 is seemingly an example of a product that was rushed into production without fully defining the problem it was trying to solve. By all accounts, the Rabbit R1 is a mobile app masquerading as a physical product. It’s still too early to know what Rabbit will do in the long run, and I’m not trying to single them out. Product failures happen all too often: someone, often a CEO or another executive, gets excited about new technology and directs a team to build a solution before fully vetting the problem they’re trying to solve. Money is committed, a team is assembled, and they’re off to the races to build an amazing new product using the latest tech. The product is released, it gets horrible reviews, and it flops. This outcome is avoidable by fully committing to defining the problem that this new product will solve. 

Marty Cagan of the Silicon Valley Product Group outlines the difference between what he calls “Feature Teams” and “Empowered Product Teams” in his book “Empowered” and on the SVPG website. He explains that these are “non-standard” nomenclatures, but I’m ready for them to be the new standard terms. All credit goes to Marty here, but I want to define these two vastly different teams using my own words:

“Feature Teams” are teams that are handed a solution or a list of features to implement and are measured on their ability to deliver the solution or list of features.

“Empowered Product Teams,” on the other hand, are cross-functional and include a product manager, designer, engineers, and QA. They are given a clearly defined problem and empowered to solve it. They are measured on the success of their solution and the outcome of the defined problem.

I’d like to see the rise of the empowered product team, with a focus on strengthening the team's abilities to define problems and understand what customers need, with increased collaboration and partnership with all stakeholders. This empowerment fits well with what I discussed in my post about building high-performing teams (HPTs). Part of creating HPTs is hiring good people, giving them autonomy, and then getting out of their way and letting them do the job. The autonomy piece isn’t as hands-off as it sounds. As a leader, there’s still plenty of work to do to make sure that teams are positioned to succeed by clearing obstacles, mentoring, coaching, identifying risks, and running interference.

Defining the Problem

Again, I'm borrowing some concepts from Marty Cagan about problem definition. Fundamentally, it's about understanding four things: value, viability, feasibility, and usability. I also think it’s important to add a “risks” component. It’s important to use the defined risks as a litmus test to help understand how new information impacts the other four criteria and if these new details mean the problem definition is no longer valid.

  • Value: Will customers be willing to buy and use the product?
  • Viability: Will the solution support the needs of the business?
  • Feasibility: Does the technology needed to implement the solution exist, and/or does the team have the expertise to build the solution?
  • Usability: Will users be able to figure out how to use the solution and integrate it into their process?
  • Risks: What might go wrong? 

Understanding and developing answers to these five questions will ensure that you have a clearly defined problem. The answers can then help you determine whether the effort is worth undertaking (“the juice is worth the squeeze”) and provide a framework for exploring solutions to the problem.

I want to add a little more about “risks.” Humans tend to be optimistic, so it's good to talk about risks and things that might go wrong to ground ourselves (check out Premortems for a process to identify risks). User these risks to consider the potential impacts of any of them being realized and develop a plan to address these issues should they arise, including pulling the plug on the project. Consider specific risks to each of the other four questions. A feasibility risk could be working with emerging tech, and a usability risk might not be fully understood until a prototype is built, or a value risk might be linked to how much customers are willing to pay.

What Next

Now that you have a well-defined problem use it to assess the next steps, comparing your problem to a portfolio of other problems to be solved. Typically, this assessment will clarify what to move forward with, what to shelve for a future date, or what to abandon. Abandoning something at this phase can be difficult, but more than likely, through analyzing the problem, you already understand why it’s the right thing to do.

After the problem is defined, risks identified, and you’ve decided to move forward, it is time to move into the solution space. All the groundwork you’ve done in defining the problem and the understanding you’ve gained will help drive possible solutions and get buy-in from stakeholders. One caveat: you’re still not going to have all the details you need when you start building the solution, and you need to continue to reassess each of the five categories as you learn more about the problem and possible solutions.

Conclusion

Reflect on the projects you're currently involved in. Are you executing tasks or solving real problems? If you find yourself on a feature team working on a predetermined list, it might be time to initiate a conversation with your colleagues or manager about shifting towards a more empowered approach.

Adopting an empowered product team framework isn’t just about changing how you work; it’s about transforming your organization's culture to one that values deep understanding, cross-functional collaboration, and genuine problem-solving. These significant changes shouldn’t be taken lightly, and they can be challenging, but the rewards of more successful products, satisfied customers, and a more engaged team—are well worth the effort. I find it more fun and rewarding to work on and lead empowered product teams. Whoever said that work can’t be fun?