Problem Solving – Aditya Kothadiya

A framework to choose which problem you should solve

Yesterday I met few friends after many years. After everybody sharing their whereabouts, it was my turn to share what I’m working on. I explained I’m working on a new venture and also shared the details of the problem we’re solving. The first question one of the friends asked was — “why did you decide to solve this problem?”

It was a great question. As they say, as a startup founder, you should be able to answer these 3 questions with high clarity and conviction –

Why this? (Focuses on problem statement and opportunity)
Why now? (Focuses on market and technology landscape)
Why you? (Focuses on founding team)

The good part was, I had thought a lot about why I want to solve this problem from various perspectives, so it was easy to answer my friend’s question.

So I thought I should share a framework with you all that I used to decide which problem I want to solve.

As mentioned in my previous post –

I researched and brainstormed a couple of problems extensively, discussed it with other people too, and eventually decided to solve a problem that I faced every single day in my professional life as a knowledge worker, and is also applicable to pretty much most of the knowledge workers in the world.

I want to fix the productivity and information loss problem that happens during every “meeting” — the necessary evil of a corporate life.

While it was a simplistic overview of why I picked up the problem that I’m currently working on, here is a list of questions I used to choose the problem I want to solve and start my next business venture —

Do I personally face this problem? If yes, do I face this problem very frequently and how frequently?
Do other people also face this problem? If yes, how many such people exist? Is it a very large population?
Do I have the basic understanding of the problem and the solution domain?
Is there a lot of progress happening in the larger space of that domain?
Do I have initial thoughts on what will be the differentiation compared to competitors?
Is it a hard problem to solve such that it will not be easy for too many competitors to enter into this space?
If I make it affordable and at the same time deliver high value, will people pay? If yes, who will pay and how much will they pay?
Will a single user receive a value from this solution or will it require more people using this service (e.g. entire team or organization) to receive basic value?
How will I sell this solution? Can I sell this using bottom-up B2C2B model or will I need a typical top-down enterprise sales model?
How will I distribute this solution? Are there any viral/referral distribution opportunities? Are there any platforms/partners that I can integrate with to distribute this solution?
Do I believe by solving this problem, will I be making a positive impact in many people’s lives and the world a better place?
Finally, if I fail to solve this problem, will I learn something new that will prepare me for the next wave/demand in the technology space?

The current problem I’ve decided to solve met all above requirements and had very compelling answers for each of the question.

I hope this framework and a list of questions will be useful to you too to choose your next business venture.

☞ If you enjoyed reading this article, then please tap or click “♥︎” below to share these thoughts with others.

A friend of mine, who’s is a product manager at a large company shared her frustration recently that there were some reorganization and changes in her company that caused her to manage a different product than she was hired to do.

I immediately resonated with her situation. I had personally experienced similar situations multiple times where I had to give up the ownership of products I had started to other colleagues and take the ownership of new things. But most vividly, I remember a conversation with a teammate of mine, who had also gone through a similar experience.

We had hired him as a Product Manager for our Mobile initiatives, but due to some business reasons, management decided to move the entire product (Engineering, Design, Product Management) to a different geolocation center. And he wasn’t happy with this decision at all. He kept mentioning that he was hired as a “Mobile Product Manager” and that’s what he had done in the past and is great at.

I acknowledged everything he was saying, and tried to give him another product in the Web domain which had similar “consumer psychology” problems, but he wasn’t happy. Then I explained him the framework that I use for any decision making for my product or personal career decisions –

First and foremost, is this in the company’s best interest?
Second, is this in my team’s best interest?
Third, is this in my best interest?

I would always put the company first and my interest last. Every single conversation and decisions I’ve made were based on this framework.

With this context, I explained to him that he was thinking about this change in the exact opposite order. He should understand why this is a good decision from the company’s perspective and support it.

Instead of getting too attached to “Mobile” domain and getting obsessed about the app ecosystem or particular features, he should think that — he was attached to solving customers’ problems and Mobile just happened to be a medium to solve those problems.

I convinced him that he should give a chance to other domain, understand those customers, learn their problems and give it a shot. The Web is just a medium through which we solve those problems today.

Eventually, he agreed and took up the new role. At some later point, he appreciated me for changing his perspective — and that’s why I remember this story vividly.

Everyone loves to be a problem solver. It’s a common believe that if you’re exceptionally good at solving problems then you have a distinct advantage to become very successful in your career.

But I cringe to give this advice to Product Managers.

Product Management isn’t a well-defined function. Its role is changing rapidly over the past few years. A common understanding is product managers identify problems in the market, come up with a bunch of ideas to solve it, define how the idea should look and work, and then give it to designers and engineers to build it.

I’ve also done this mistake in the past too. When I was new in my Product Management career, I received the feedback from a VP of Engineering — “Aditya, can you please mind your problem boundary?”. That feedback was harsh, but it completely opened my eyes. I realized what I was doing wrong. But I took that feedback positively and quickly stopped my day to day involvement in coming up with different ideas and solutions.

Since then I strongly believe —

Product Managers shouldn’t be problem solvers. Their focus should be to —

identify the right problems that their company and a team should solve
prioritize which problems to solve first and which can wait later
communicate the rationale behind these decisions to their team and other stakeholders

Essentially Product Managers should identify “what” problems they should solve, “why” their company and a team should solve it, “when” those problems need to be solved and then communicate all these things really well to their Design and Engineering teams and to other stakeholders.

And then let Design team come up with “how” it should work and look, let Engineering team come up with “how” it should be built, and let Sales and Marketing teams decide “how” to give it in customers’ hands.

The most important reason for letting other specialized teams to solve specific problems is — they feel valued and empowered.

If you, as a product manager tell a designer what to design and how it should look like, then they don’t appreciate it. Similarly, if you tell an engineer how to architect a solution or use specific technology stack, then they don’t like it. They don’t feel empowered enough to take key decisions. If you take decisions on behalf of them, they don’t feel as motivated and involved and then hesitate to take responsibility for those decisions.

In fact, I believe that we should change the title of a “Product Manager” role to “Problem Manager”. Because of the “Product Manager” title, there is this notion that they are the owners of the product and get credited for the success or blamed for the failure.

In reality, they’re just team members playing a particular role in identifying and prioritizing problems. The rest of the team is responsible for solving those problems in elegant, scalable and profitable ways. While product managers are the face of their respective products, they rarely make or break the product. It’s a collective team who is responsible for the success or failure of the product.

By calling Product Managers as Problem Managers, it will keep them away from solving problems and will remind them to focus only on identifying and managing problems.

Having said all of this, if you’re a very early stage company and can’t afford to hire specialized Designers, Engineers, Marketers, and Salespeople, then yes, as a Product Manager you might need to play different roles and get into “problem-solving” mode too. But as the company starts scaling, you should let go your other responsibilities to specialized teams and focus only on identifying the right problems and prioritizing them.

☞ If you enjoyed reading this article, then please tap or click “♥︎” below to share these thoughts with others.