The courage to own the problem, take risks, and deliver great results

“If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.”― Albert Einstein

Background

A few years ago, a startup hired me to join their team and help them with launching their main product. They were trying to crowdsource news creation to people living in different locations and allow users to use the map to consume these geo-based news.

The Problem

At first, they wanted me to help with improving the process. The founding team was concerned about the speed and quality of the new news platform.

They invested 2 years of their time, spent more than $200K from their own pocket, family and friends, and they yet to see it live in production. They have quality issues, sure! However, I was certain that this wasn’t their biggest problem! They spent 2 years and more than $200K without talking to customers. I decided it is important for them to know my opinion and where I stand. I have a few, but big challenges:

1. Why would they listen to me? I’m a new addition to the team
2. They already spent a lot of money and wasted tremendous amount of effort! it is going to be hard for them to admit it. It is going to be easier, and more convenient, for them to fire me than to admit thier mistake.
3. I was confident that they are going to fail if they proceed in this path. It will not be long before they kill the project, especially that they were tight on money
4. They were expecting results within weeks! From experience, fixing the process will take a little bit of time, probably more than the runway they have.

Potential Solutions

I had an informal discussion with a few members of the team, and I came up with the following options on how to proceed:

1. Just forget about it and do what they want me to do
2. Discuss my findings with the founders openly and ask them to change their strategy and admit that they were wrong.
3. Discuss my findings with the whole team – this will might create enough pressure to force the founders and CEO to rethink their strategy.
4. Prepare them to fail, lead them to understand that they have a problem, help them shape the solution, and help them in recovering from this failure.

The Solution

I went with the with number four, and I started preparing to guide them through the inevitable failure. Here is what I did:

1. I started with the process. I coached them on how to use Scrum, but with one tweak: NO PO! Their product manager was acting as a buffer, not a good one, between the dev team and the CEO. There was no interactions with the real users.
2. This pushed everyone, including the devs, to brainstorm ideas, and learn more about the users
3. As a result, they started debating some features and why they need them. The founders felt obligated now to explain why they are building these features.
4. To help resolve the disagreement, I facilitated discovery sessions with the founder and some of their potential users.
5. I asked them to focus on one users segment, the one they are most familiar with and excited about and brainstorm what could be removed from the product to make it good enough for them.
6. Next step was to trim down the product by removing all the features that they didn’t need for the launch. Within two weeks they launched the product to their customers, and they failed – the customers didn’t even use it.
7. I helped them understand the feedback, brainstorm more ideas and pivot.
8. They had a new service/product in place ready to be tested within few weeks
9. Their first customer payed them $5000 within two months.
10. More than one year later and they are still growing, attracting more customers, winning awards –

Key takeaways

1. Always solve a customer or a user problem.
2. If you have to fail, it is better to fail as fast as possible. Accelerate the failure but always have a plan to build the team back up.
3. Having multiple buffers between the people building the software and the really users/customers is not a good idea. This is important for startups and for new projects/initiatives. You want a sign of sight between devs and the people they are building the software fore.
4. Don’t be afraid to own the problem and to take risks.
5. Always spend time trying to understand and define the problem.

Resources

• Accelerate the inevitable failure, but prepare a recovery plan by Yousef Ghandour