Categories
Uncategorized

Product Managers should be Problem Managers, not Problem Solvers

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 –

  1. First and foremost, is this in the company’s best interest?
  2. Second, is this in my team’s best interest?
  3. 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.

Categories
Uncategorized

Why Do Many Smart Engineers Fail To Build A Successful Startup?

Recently, I had a couple of friends reaching out to me to discuss their startups’ progress and get some advice on how to take it to the next level. In all these interactions, there were some common patterns –

  • Most of the founders are smart engineers and some of them have worked with Google, Amazon, eBay, Oracle, etc.
  • They have a B2C (focused on consumer) product, which didn’t have any transactional (i.e. user paying in some form) business model
  • They have been working on it for over a year and have a working product or technology, but are struggling to get users and increase the engagement for their product
  • They are first-time entrepreneurs

What surprised me the most is — while there is so much content available on the internet today about how to start a startup, how to follow a lean methodology, how to do a customer validation, how to build viral hooks in your product, how to implement various growth hacks, etc. but still, these entrepreneurs are making the same mistakes that many entrepreneurs have made 10 years ago.

My hypothesis is —

  1. These entrepreneurs are not investing enough time in learning as much as possible from others’ experiences by reading books, blogs or listening to podcasts and avoid some common mistakes
  2. They are not able to let go who they are and what background they came from (engineering) and grow into a new role (founder), which is required to build a successful product and a company

To build a successful software company, there are 3 skills that are essential in the founding team —

  1. Building a great technology
  2. Building a great product
  3. Growing your users/customers

After talking with these smart engineers I realized— they had largely focussed on #1 but weren’t giving enough attention and importance to #2 and #3.

If you are a great technologist and aspire to build a technology product company, then either you grow from an engineer to a product manager/designer, and eventually into a marketer/sales person based on if it’s a B2C (consumer) or B2B (SaaS or enterprise) product or have someone on the founding team who is specialized in these skills.

As an engineer, the technology innovations you’re doing are really admirable and absolutely essential for a startup. Being a smart engineer is the greatest asset you can have in this startup world. Every other “idea” guy wants you to be on their team to make their idea a reality. So by no means, I’m belittling the value and the need of having strong engineering members on the founding team.

But I want to emphasize the need of having someone with strong product sense and/or great marketing/sales skills as well.

If you don’t prefer to have someone with product design/management in your team, then you will need to play a role of a product manager/designer to truly understand your users/customers and build something they want and solves real problems.

And eventually, you will also need to become a marketer/sales person and reach out your target users/customers, talk to them and convince them to use/buy your product, and eventually know how to do it at scale and do it repeatedly.

Just because you are a great engineer or technologist, don’t assume you can build a great product.

And just because you are a great product manager, don’t assume you can build a viable business.

There is a difference between a technology and a product — most people confuses this. And there is also a difference between product and business.

Typically, technology is an applied science. We build new technologies using some of the breakthroughs in the science world to achieve some objectives — i.e. to make existing things (technologies) faster, cheaper or better (larger, smaller, last longer, etc.)

On the other hand, a product is an applied technology. We build products using multiple technologies to solve specific problems that a user faces or tasks she wants to do.

And in the end, a business is an applied product. You need to take your product and reach out to your target users/customers and have them use it, which helps you generate a sustainable economic value.


As an engineer, we gravitate towards building great technologies. Making that code run even faster, improving the performance and accuracy of that function, etc. And some engineers are really good at that. And that’s why they get hired at some of these great companies, who have built some of the greatest products for mass consumers. But just because these companies have shipped great products, the engineers who work at these great companies start believing that they can also build great products on their own.

While that’s absolutely possible, it doesn’t come handy without you putting any efforts towards achieving that goal. If you are a smart engineer and eventually want to build a great product too, then your existing technical skills are a great asset but are not sufficient. You will need to invest considerable time to achieve those product and business skills as well.

I would recommend learning these skills –

  • Consumer psychology
  • User experience design
  • Prioritization
  • Communication
  • Business acumen

Let’s dive into each one in detail –

Consumer psychology

If you aspire to build a product that is not only useful (solves a real pain point) and usable (effortless and intuitive to use) but also delightful (that creates happy emotions).

You will need to get into user’s head to understand what specific problem they want to solve and what specific outcome they want to achieve, what effort it takes for them to do that, what emotions they feel after they achieve that outcome, etc.

Once you understand the consumer psychology very well, you will nail the product that will resonate with them very well and chances of them using it actively and recommending it to their friends will increase drastically.

User experience design

As per Wikipedia, user experience design (UXD or UED) is the process of enhancing user satisfaction with a product by improving the usability, accessibility, and pleasure provided in the interaction with the product.

The last part is very important — “interaction with the product”.

This is the most common mistake engineering founders make — they confuse UX Design with UI Design (User Interface Design). UX Design is a more analytical and research oriented, while UI Design is largely about graphic and visual design. While both are crucial, nailing the UX design (usable) is more critical than the UI design (look and feel).

UX role is quite complex and challenging. It involves consumer analysis, competitor analysis, product strategy, content strategy, wireframing, prototyping, usability studies, etc. So I’m not suggesting you do this everything on your own and become an expert in this. But if you understand what each function does and practice some aspects of it, then it will go a long way.

At the minimum, to provide a great user experience, focus on the lifecycle of a consumer who wants to use your product. You need to understand what they do in their life before they use your product and after they use your product. And repeat that exercise few times. This will help you understand your target consumers’ life really well to build a product that fits into their lifecycle.

Prioritization

Another most important skill you will need to learn is — prioritization.

As a technologist, you get sucked into optimizing things that are not required on the day one. You tend to build advanced technologies in-house instead of leveraging off-the-shelf services from the 3rd party providers. You believe that that’s your core IP and needs to be built in-house. You argue that 3rd party providers are generic platforms and won’t be as effective solving your specific use case. While that all is true, it’s still a mistake to optimize for these things before you even have any product-market fit. You can always build advanced technologies in-house as you start scaling.

I recently learned this from DJ Patil’s Twitter update

  • Dream in years
  • Plan in months
  • Evaluate in weeks
  • Ship daily

And –

  • Prototype for 1x
  • Build for 10x
  • Engineer for 100x

And –

  • What’s required to cut down timeline in 1/2?
  • What needs to be done to double the impact?

This is such a great prioritization framework that forces you to focus on delivering maximum value at minimal wastage. You will need to learn to be ruthless in your prioritization for all activities.

Communication

While this may sound very obvious and cliche, but written, verbal, and nonverbal communication skills are actually the most important traits you will need to master to gain credibility as an effective and trustworthy founder.

While you might be great at explaining technical details extremely well to your peers, now you will need to communicate the problem, the value and the benefits of your product to various different stakeholders — potential teammates, advisors, investors, prospects, clients, etc. You will need to wear a different hat every single time based on who is in front of you and communicate effectively in multiple languages — executive, development, strategic, tactical, etc.

Your written and spoken communication is going to be an absolutely crucial skill for your sales or marketing efforts. You will need to communicate what value your product delivers and able to align those benefits to the problems prospects have shared and eventually influence them to use or buy your product.

And don’t forget, you will need to be equally great at “listening”. Sometimes you’ll learn more when you’re actively listening as much as you are speaking or writing.

Business acumen

While this is a broad topic, having business acumen boils down having a minimum level of expertise in strategy, finance, operations, marketing, and sales. You may not need to be the expert in any one of these skills, but while communicating with advisors or investors, you will require some level of fluency and confidence in these business languages.

You will need to understand the basics like —

  • what’s the unit economics — how much it costs you to serve a customer?
  • what’s your business model — transactional, subscription, revenue-share, or ad-based?
  • how much does it cost to acquire a new user/customer (CAC)?
  • what’s the market opportunity — what’s the total available market (TAM) size, what’s the serviceable available market (SAM) size, etc.?

Now you might say, for a smart technologist by profession, learning all these skills means deviating from their core focus. While that may be true, the key question is — do you want to continue to stay only as a technologist or do you want to grow into a founder role?

There is nothing wrong with staying as a technologist throughout your startup, but then make sure you have someone on the founding team who has a great product sense and a strong business acumen.

But if all founders have technology background, then make sure at least you have someone in the founding team who wants to grow into a product manager and eventually into a business operations/marketing/sales role.