Escaping the Build Trap: How Effective Product Management Creates Real Value

by Melissa Perri

The tasks of focusing on the Product Kata and identifying which phase you are in and what tools are available there are key to successful product management.

This is one of the first things every company should do — implement a metrics platform. Amplitude, Pendo.io, Mixpanel, Intercom, and Google Analytics are all data platforms. Some, like like Intercom and Pendo.io, also implement good customer feedback loops, because they provide tools to reach out to customers and ask questions.

Having a metrics platform implemented, whether it’s homegrown or third party, is essential for a product-led company because it enables product managers to make well-informed decisions.

User research, observations, surveys, and customer feedback are all tools that you can harness to better explore the problem from a user standpoint.

User research, in this case, is not to be mistaken for usability testing, which involves showing a prototype or website and directing people to complete actions. There, you are learning whether they can use and navigate the solution easily, not whether the solution actually solves a problem. This type of research is called evaluative.

Problem-based user research is generative research, meaning that its purpose is to find the problem you want to solve. It involves going to the source of the customer’s p...

This type of thinking is exactly what lands us in the build trap. When we use an MVP only to get a feature out quicker, we’re usually cutting corners on a great experience in the process. Thus, we sacrifice the amount we can learn from it. The most important piece of the MVP is the learning, which is why my definition has always been “the minimum amount of effort to learn.” This keeps us anchored on outcomes rather than outputs.

Concierge experiments deliver the end result to your client manually, but they do not look like the final solution at all. Your customers will understand that you’re doing it manually and that it’s not automated. It’s one of my favorite experiment types because it doesn’t involve coding and it’s quick to get started. Because you get to work with your customers closely, there is a ton of feedback flowing through and there are tight learning loops.

Concierge experiments are particularly interesting for B2B companies because this is how many of these companies got started — by taking on the work for the customers and then later automating it. By taking on the work yourself, you can learn how to build the software correctly the first time.

The idea behind the Wizard of Oz is that, unlike the concierge experiment, it looks and feels like a real, finished product. Customers don’t know that, on the backend, it’s all manual. Someone is pulling the strings — just like the Wizard of Oz.

Concept testing is another solution experiment that focuses more on high-touch interaction with the customer. In this case, you try to demonstrate or show concepts to the user to gauge their feedback. These can vary in execution, from landing pages and low-fidelity wireframes to higher-fidelity prototypes or videos of how the service might play out. The idea here is to pitch the solution idea in the fastest, lightest way possible to convey the message.

It’s important to note that this type of experiment tends to be more generative than evaluative. Just like problem research, generative solution experiments help you to gain more awareness around what a user desires in a solution. When you show the concept to users, you are asking them to put themselves into the scenario in which they are experiencing the problem, and you are asking them questions about how the solution would or would not solve their problem.

So, the company turned to a solution experiment. The team put together a rough video, demonstrating what Dropbox could do. It had not built a demo or a prototype but instead used video editing to demonstrate what it would look and feel like to the investors.

But, if you don’t go the design sprint route when creating your prototype, which includes heavy user research before diving into design, you can easily become stuck trying to solve a problem you don’t yet understand. Prototypes don’t make sense when you need to validate the problem. In this case, you’re spinning your wheels creating shiny designs that look great but don’t help you to learn what you need to learn. That’s why you need to focus on exploring the problem before any solution activities.

The team used a technique called story mapping, created by product management veteran and consultant Jeff Patton, to make sure they all understood the work and to prioritize the first release. They then prioritized the work, cutting out a few less-critical components in the first version.

After the direction is set for the product vision, it’s important to make sure everyone understands the context and work that needs to be done. Story mapping and North Star documents are two ways to help teams find alignment around the vision.

North Stars are great for providing context to a wide audience. They should be evolved over time, as you learn more about your product. It’s important to note that this is not an action plan — it does not include how the team will be building the product. That is where story mapping comes in.

In Agile development, there is a concept called the Definition of Done. It is defined by the Scrum Alliance as a “checklist of valuable activities required to produce software.”1 When teams create their Definition of Done, it’s usually around finishing building features required to ship a product.

Instead, teams should be working like the team at Marquetly, by setting the success criteria before launch, while measuring and iterating until they reach it. Version 1 should be looked at as a hypothesis, just like any other work. And, if we launch the feature and it is not hitting our goals, we need to be comfortable rolling it back and trying something else.

The product-led organization is characterized by a culture that understands and organizes around outcomes over outputs, including a company cadence that revolves around evaluating its strategy in accordance to meeting outcomes.

We need a cadence of communicating strategy that matches our strategic framework. Remember our four levels of strategy: vision, strategic intent, product initiatives, and options. Each of these is on a different time horizon, and progress toward them should be communicated accordingly.

I recommend aligning your company around certain terminology to determine stages of development so everyone understands which activities are happening. We use these four phases:

Creating working agreements and roadmaps that can be communicated to customers is key to developing a good relationship between product and sales. You can make an agreement with the sales team that anything being released as GA — or anything further along in Beta — can be added to its sales roadmap.

Corporations love to talk about risk management. The irony is that experimentation is the ultimate risk-management strategy because, when you experiment early, you can prevent the failure of something you will have spent billions of dollars on later.