What Kind of Product Manager Do I Want to Be?

Have you ever tried to explain what a Product Manager does? Even if you are a Product Manager it can be hard to explain your own role or narrow it down to a simple definition! That is because Product Management in software can entail many things. Product Management is an organic function rather than a snapshot of skills and responsibilities. A Product Manager owns the lifecycle of a product, from concept to delivery, from launch to maintenance and optimisation. And everything that is in between.

It is, however, common to split Product Management into two main functions: Product Discovery and Product Delivery. Some companies even created two roles thus fostering this division: one more focused on discovery and analysis, and one exclusively for product delivery. But, does this division make sense? Which role should I be doing? Which one is more important?

Product Discovery vs Product Delivery

Product Discovery is about understanding the issues customers are facing and selecting one or more to solve — finding the opportunity. This opportunity might be a specific problem that is not being properly addressed by any other product, or a problem that we believe we can solve better. There are a lot of different techniques we can use to do that research, such as analyzing product data, market data, interviewing current users or conducting surveys. The opportunity will arise as a set of outcomes the customer expects to fill to get that job done.

Once we have an opportunity identified and well defined, the right time will come to design and deliver the solution. It involves all the process of ideation the new product, putting together lo-fi designs, wireframes, hi-fi designs, and then breaking this down into deliverables and getting it done, shipping this new product to market. And this is what is commonly called Product Delivery.

This is how most people in the business look at Product Management and Software Development. Two different phases of product development: 1st Product Discovery and 2nd Product Delivery. Discovery is seen as a Research phase, and delivery is split into Design and Development. Analysis is feeding into new discovery and product optimization.

As in the image above, Product Discovery comes first, then when the product is carried out it is often awarded with a tiny percentage of resource and time allocation. Research entails focus groups, user research, customer reviews analysis, an internal brainstorming session to define what to do next, a request from your biggest customer or simply something your CEO requires. Have you ever thought about which of these is most common in your organisation?

Then we go into the Delivery Phase. It is time to design the solution. With the research results as a background and the Product Manager’s inputs, design starts putting together some wireframes to work out some solutions. Designs are reviewed usually with the Product Manager and with internal stakeholders to validate the approach until a final hi-fi design is achieved for the product and we’re ready for development.

Agile is most used in development phase as a tool, rather than a mindset. Work is planned and roadmapped — split in different sprints. Often entire projects are pre-planned in two-week sprints, often without a clear sense of outcomes or deliverables, without a minimal focus on incremental delivery of value. But hey! They do use sprints as well as Agile retrospectives! “If Agile is not that then we don’t know what it is!”

But we can go over what being Agile really means on a different occasion…

After shipping the product, companies then analyze impact. Either through surveys, interviews, website analytics, or using metrics like conversion, sign ups or whatever metric measures the intended goals of the new product or feature may present.

Is Product Development That Linear?

Whilst, talking with a Product Manager in a tech company recently I was told the following: “Discovery is done. Design is ready as well. Now is pretty much delivering on top of that”.

The problem with this interpretation of Product Management and Product Development is that it is linear and sequential. The whole process is far from Agile, flexible and iterative. It is actually quite waterfalish. From initial research to final shipping the whole process can take months. What if our assumptions and hypotheses are wrong? What if the solution we are building is not right?

That’s why we should look at Product Management as a cyclical process. A short cyclical process, repeated again and again. And to me all of that is Product Discovery. Discovery is researching, formulating hypotheses, finding opportunities, designing, testing, building prototypes, testing, building incrementally and always testing and validating. Pivot and go back to reformulate the solution if needed.

As in this staircase the path to a product is circular, it advances as we move in circles, and the end is unknown. You need to go down those circles to start seeing the end more clearly.

I come from a science background. I majored in Microbiology and did my time in the lab bench, formulating hypotheses for a given problem, writing test protocols, repeating experiments over and over with slight changes to try to understand a biological process. Almost 20 years later, after leaving science and having embraced a career in Software and Product, I find it quite ironic how I am applying the same principles to find the right products to build. Life does go full circle.

In my view, Product Discovery is Product Management. Product Discovery is the whole process. It is not a phase or something you do when there’s time to kill. The full process of finding the right problem to solve, finding the opportunity and testing solutions until you deliver something to the customer, over and over again: this is Product Discovery as well as Product Management.

Product Management is Product Discovery

Summing up, Product Management is Product Discovery, and Product Discovery is also Delivering. You can’t discover without delivering, testing, feedback or learning.

Product Management = Research + Delivery = Product Discovery

Product Management = Product Discovery

If we have in mind that Product Discovery should be present in all we do as Product Managers, and that in fact they should be the same thing, it will be easier to always have a mindset of testing and learning, of not settling on our assumptions, of not falling in love with our solutions. Research and delivery should always be hand in hand, running in parallel.

The above image tries to capture this cyclical process of Product Discovery, or Product Management. The idea of this process is that we never take too long running one of these cycles, before testing and learning and starting all over again.

We can, and probably should at the start of a project, run several iterations of the research cycle, until we nail an opportunity worth pursuing. We start with a problem, analyse it and define it better, breaking it down into different problems, and later into opportunities.

Then we test if those opportunities are worth chasing. Is there a market for it? Is that opportunity being addressed by anyone? Are there other angles on that opportunity? We can run a few of these cycles. One cycle is probably not enough, but also don’t spend infinite cycles on the theoretical side of the process. We need to validate the opportunities with potential solutions.

MVP is not a Product

That’s when we start working on the right cycle of the double loop. We hypothesize and ideate solutions around those hypotheses and then build something that allows us to validate the solution. And when I say build, that doesn’t necessarily mean coding anything or putting up a physical product. This is where the MVP concept comes in. MVP stands for Minimum Viable Product and was made famous by Eric Ries’s best seller “The Lean StartUp”.

MVP is another concept very often misused by companies. It is commonly used to label a first delivery/release of a product with a supposedly stripped-down feature set, a product with Must Haves only. That is not an MVP.

An MVP is the next thing we can put together that allows us to prove our product will work. An MVP can be an interactable wireframe, a prototype, a product with mock data, a video demo, etc. And once validated, we go into the next MVP.

In 2007, San Francisco roommates Joe Gebbia and Brian Chesky noticed a problem. Nearby hotels were all booked up ahead of IDSA, a large Bay Area design conference. So, they decided to test their assumption that certain people would be willing to pay to stay at someone’s house in lieu of a hotel by creating a simple website with a listing for their own flat to test whether people would be willing to sign up. “AirBed&Breakfast” worked. They got three guests to stay at their flat, validating their concept. Today it is known as AirBnB. Amazon started with a very simple page with a small listing of books as a test that people would buy stuff on the internet, back in 1994. To cut down risk, they would order the book from a distributor as soon as the book was ordered in Amazon, to then ship it to the customer.

Delivering is Discovering

Eventually, we will have enough proof that our idea will work so that we can plan a larger feature. But that plan needs to be lined up always as the next test. We should be delivering iteratively new pieces of value that are testable, so we can immediately get feedback (data, reviews from users or stakeholders, etc) that confirms the direction or makes us stop and pivot. We shouldn’t need 12 months project to find out our new product is a failure. That’s why we use Agile, most commonly Scrum. Each Sprint should be meant to deliver on new pieces of value that are testable, preferably with real customers. Agile shouldn’t be just something hype to make us look innovative. Each new piece of functionality we put out there is our next opportunity to find out if we are going in the right direction or if we need to pivot to a new direction, a new opportunity and a new solution.

Answering to the initial question, we shouldn’t really choose Delivery or Discovering as they are tied in together. They feed on each other. Separating these activities through different roles may hinder this dynamic and end up in silos that lead to the same old sequential mindset.

At craftable we foster this mindset and take it to our projects, partners and clients. We know that more than a shift in methodology this requires a shift in mindsets and attitudes, which is harder. That is why Product Management is also a leading role that should guide and coach different parts of an organization into a product discovery mindset, with patience and respect by the organization’s culture and structure and knowing that there isn’t a one fits all formula.

Check out more about craftable’s work at our website

What Kind of Product Manager Do I Want to Be? was originally published in craftable on Medium, where people are continuing the conversation by highlighting and responding to this story.