Inspired: How to Create Tech Products Customers Love (Silicon Valley Product Group)

by Marty Cagan

If your company does not have any data analysts, then responsibility for this typically falls on the product manager. If this is the case, you'll probably need to plan to spend significant time diving deep into the data to understand your situation and make good decisions.

However, what's not okay is if your company doesn't have test engineers, and your engineers don't do the testing either, and they are looking to you as product manager to do the quality testing.

Since the head of product is first and foremost responsible for building the skills of the product managers, a dedicated principal product manager is able to focus on the product itself and is readily accessible as a critical resource to all the product managers, product designers, engineers, and test automation staff.

There are so many interactions and interdependencies—and so much necessary institutional knowledge of the business and the users and the customer journey—that at least one person must review everything going on with the product that is going to be visible to the user. You can't expect any individual product manager or designer to be able to have this all in their head.

I view product discovery as the most important core competency of a product organization. If we can prototype and test ideas with users, customers, engineers, and business stakeholders in hours and days—rather than in weeks and months—it changes the dynamics, and most important, the results.

One of the most basic of all product lessons learned is that trying to please everybody at once will almost certainly please nobody. So, the last thing we should do is embark on a ginormous, multi‐year effort to create a release that tries to deliver on the product vision.

There's no single approach to product strategy that is ideal for everyone, and you can never know how things might have gone if you sequenced your product work differently. I tell teams that the most important benefit is just that you decided to focus your product work on a single target market at a time. So, all teams know we're tackling the manufacturing market now, and that's the type of customers we are obsessing on. Our goal is to come up with the smallest actual deliverable product that makes these manufacturing customers successful. Ideas that come up that pertain to other types of customers or markets are saved for future consideration.

The difference between vision and strategy is analogous to the difference between good leadership and good management. Leadership inspires and sets the direction, and management helps get us there. Most important, the product vision should be inspiring, and the product strategy should be focused.

Product strategy needs to be aligned with sales and go‐to‐market strategy.

The purpose of product discovery is to address these critical risks: Will the customer buy this, or choose to use it? (Value risk) Can the user figure out how to use it? (Usability risk) Can we build it? (Feasibility risk) Does this solution work for our business? (Business viability risk)

approach discovery with the mindset that many, if not most, of our ideas won't work out. The most common reason for this is value, but sometimes the design is too complicated, and sometimes it would take far too long to build, and sometimes there turn out to be legal or privacy issues. The point is we need to be open to solving the underlying problem in different ways if necessary.

fall in love with the problem, not the solution. Why is this so important? Because, more often than not, our initial solutions don't solve the problem—at least not in a way that can power a successful business.

I believe the major risk facing most efforts is value risk. On a startup canvas, this shows up under solution risk—discovering a compelling solution to customers. A solution that your customers will choose to buy and use.

we need to embrace product discovery as the most important core competency of the startup.

whether your constrained resource is cash or management's patience, you need to make sure you primarily use your time to discover a winning solution. Get that risk resolved first and then you can focus on the other risks.

We usually do usability testing with a high‐fidelity user prototype. You can get some useful usability

Most of the time, when we do a usability and/or value test, it's with the product manager, the product designer, and one of the engineers from the team (from those that like to attend these). I like to rotate among the engineers. As I mentioned earlier, the magic often happens when an engineer is present, so I try to encourage that whenever possible.

You should have one person administer the usability test and another person taking notes. It's helpful to have at least one other person to debrief with afterward to make sure you both saw the same things and came to the same conclusions.

we want to learn whether the user or customer really has the problems we think they have, and how they solve those problems today, and what it would take for them to switch.

When testing, you'll want to do everything you can to keep your users in use mode and out of critique mode. What matters is whether users can easily do the tasks they need to do. It really doesn't matter if the user thinks something on the page is ugly or should be moved or changed.

If the value is there, we can fix everything else. If it's not, how good our usability, reliability, or performance is doesn't matter.

fake door demand test. The idea is that we put the button or menu item into the user experience exactly where we believe it should be. But, when the user clicks that button, rather than taking the user to the new feature, it instead takes the user to a special page that explains that you are studying the possibility of adding this new feature, and you are seeking customers to talk to about this.

landing page demand test. We describe that new offering exactly as we would if we were really launching the service. The difference is that if the user clicks the call to action, rather than signing up for the trial (or whatever the action might be), the user sees a page that explains that you are studying the possibility of adding this new offering,

I want to emphasize the most important point for technology companies: If you stop innovating, you will die. Maybe not immediately, but if all you do is optimize your existing solutions, and you stop innovating, it is only a matter of time before you are someone else's lunch.

qualitative testing is not about proving anything. That's what quantitative testing is for. Qualitative testing is about rapid learning and big insights.

it's important to conduct the usability test before the value test, and to do one immediately after the other.

In discovery A/B testing, we usually have the current product showing to 99 percent of our users, and the live‐data prototype showing to only 1 percent of our users or less.

The modern alternative to roadmaps discussed here addresses both of these concerns. Teams work on the prioritized business objectives determined by the leaders; we share our key results transparently; and we commit to high‐integrity commitments when critical delivery dates are needed.

In terms of the stakeholders, the product manager has the responsibility to understand the considerations and constraints of the various stakeholders, and to bring this knowledge into the product team. It doesn't do anyone any good to build things that may work for the customer, but then at some review meeting find out that you're not allowed to deploy what was created.

I think of product culture along two dimensions. The first dimension is whether the company can consistently innovate to come up with valuable solutions for their customers. This is what product discovery is all about. The second dimension is execution. It doesn't matter how great the ideas are if you can't get a productized, shippable version delivered to your customers. This is what product delivery is all about.