How to Think Like a Product Manager?

Writing code is one of the most fundamental skills in any industry today. But while training and diligence suffice to make a competent developer, the problem of turning that code into a product still pertains. And only a handful of people have the knowledge, experience, and mindset to do that.

If you want to become an expert on turning code into products, you'll need to learn to think like a product manager. Product thinking lets you go beyond engineering solutions to existing problems and from learning to define those problems to building solutions holistically and systematically.

Identify how you think so you can change

The first step on this journey is to understand how your brain works and to identify your way of thinking. After all, if you don't know where you're starting from, how can you tell where to go?

For instance, if you're coming from a business background, your way of thinking will probably be client-facing. As a listener to an interpreter, you help others focus and prioritize — but ultimately the details are beyond your control.

On the other hand, coming from a technical background, your way of thinking will be about features and implementation. A solution is something that performs a function well, but it's not really your concern what exactly that function is.

Both of these perspectives are valuable for their own sakes, but a product manager needs to integrate them — not so that they can perform both equally well, but to help the business and technical sides complement each other and work hand in glove. And this requires a different set of skills entirely.

As Martin Eriksson, founder of ProductTank, once explained, product management lies at the intersection of user experience, business, and technology. Whichever domain you are coming from, learning from and including the others will improve your product thinking, allowing you to make tough decisions that involve and affect all three and champion a product that succeeds on the merits of each, even when they may seem to compete.

Build over buy

Casey Neistat is a vlogger whose YouTube videos are watched by millions. He often talks about the concept of "Build over Buy," and it's clear that the philosophy has contributed to growing his audience and influence.

Build over Buy basically means that if you want to do something your way, you're not going to find an off-the-shelf solution. Every person and every problem is distinct, and even if there are lots of similarities, it's the differences that define you and your work.

For Niestat this meant building his own hardware, vlogging gear, editing style, and so on. But it's equally true in product-related problems. You're not going to find the right answer in an app store or by a quick search.

Because the question is defined by its differences, so is the solution. If your approach to solving the problem focuses on differences rather than similarities, the result will be forward-thinking and personalized. It's just a question of developing and applying your skillset so that you can quickly and accurately identify those differences.

Success means not just solving your own problem, but creating visibility for the problem-solving process you led, which may be more valuable than the solution itself.

Solving from scratch

When you start on a new product, the only way to truly fit it to the client's needs and make it your own, is to start from scratch. That doesn't mean you have to build everything along the way, but it's important to begin without assumptions about what you have to make, what you've already done, what's easy, and what's hard.

This approach matters regardless of the scope or restrictions of a project. Just because your client doesn't have enough budget for the project, doesn't mean you get to skip the important foundation of the idea to work.

It might even feel like a waste of your time, or your client's time, to start from zero — especially if the client wants to skip ahead, which is a definite possibility. To build the best solution, draw your road map as completely as you can from the starting line. If you layout your product vision correctly, both the client and the people who take on the work will thank you. It will be better and more recognizable as your own.

Get comfortable arriving last and coming in first

The old adage that haste makes waste is applicable in product work as well as anything else. But sometimes it can actually work against you to be first to market with a product. To be first could mean that someone is capitalizing on a real innovation, but it could also easily mean that the competition is simply taking the time to build a better product in the same space.

Apple is the undisputed master of this approach. Remarkably, few of its most recognizable products were actually Apple firsts.

For instance, smartphones included a facial recognition phone unlocking system years before Apple did. Yet somehow whenever we talk about this type of feature, we call it "Face ID." Why is that?

Because Apple wasn't looking at how to respond to the competition (a business mindset) or how to implement the same feature better (a technical mindset); instead, Apple took a whole product approach and wrote out the roadmap on its own terms, asking fundamentally what the problem is that they were designing a solution to. And meanwhile, of course, they were learning from the competition's mistakes.

This not only resulted in a market that was both technically mature and aware when they launched, but also positioned them as more thorough than the others. Face ID wasn't just a feature — it was a new standard for iPhones to the point where the old method was completely removed. And since then, the product hasn't really changed beyond invisible improvements, because it was designed from the start to be complete on arrival.

Key takeaway

Product managers have to think in a way that synthesizes technical and the business aspects, as well as the user experience, market reality, and various other factors, and create a way forward that involves all of them.

If you enjoyed reading this article, you should also read my previous article on why does your team needs a product manager. Find out here.