From Lean Startup Circle at Capital One Labs, December 17, 2013.
One of the big challenges with doing innovation in any setting is that most people are afraid of failure, and when you’re afraid to fail, you don’t take the risks that are necessary to keep creating and innovating.
Most professionals have had the idea that “failure is bad”, “failure is not acceptable”, or “failure is final” drilled into them through 16 years of schooling by the time they enter the workforce. We take tests in school and only get one shot to get it right, which is not usually how it works in the real world.
Recognition of this disconnect has led to a sort of “counter-cultural movement” among entrepreneurs of celebrating failure. While I understand how we got here, I think it’s an over-correction. We’re trying to balance one extreme out with another.
The problem with celebrating failure is that, unless you’re learning something, it’s still just failure.
We need to stop celebrating failure indiscriminately, and instead celebrate the learning that can come out of failure (and sometimes out of other things). Failure might be a necessary cost, but it’s the learning that helps us improve our creations and make the next ones better.
How often has your company run a focus group or usability test and generated big fat report that just sits on the shelf somewhere full of great ideas the never get implemented?
You can do all the research you need, but if you don’t use it in your decision-making process, you’d be better off not having done that all.
In order for that data in the report to get used, it must be highly visible and personally relatable. We all know what happens when the team has to seek out the results and can’t see how they relate to their work.
Enter the Information Radiator[box type=”info” style=”rounded” border=”full”]An information radiator is a large, highly visible display used by software development teams to track progress.[/box]
One of the best approaches I’ve ever seen to achieving salience like this is a variant on the information radiators used for things like bugs fixed, bugs reported, or server uptime.
After conducting a series of recorded usability session with end users, one particularly clever usability expert I know convinced the team to let him put data from the sessions on the information radiators in the office (in this case, large monitors). Rather than reduce the users to a set of charts, he compiled the recordings of each session, edited them down to the biggest pain points, and played this highlight reel of ‘users having difficulty’ in a loop on the big screens around the office.
Every time people came in the office, they saw the endless loop of users trying and failing to use the website. Having those results staring at them every day was a great way to motivate the team to fix the confusing spots, empathize with the user, and raise the salience of usability problems to a level normally reserved for technical errors.
I’ve had several conversations recently about the nature of product management and the role of product managers. One thing that kept coming to mind was an old post by Martin Eriksson, which defines the product manager as the person who sits at the intersection of UX, Tech, and Business.
Eriksson says that the role of the product manager is to:
- assess and articulate the needs of the user,
- understand business goals and constraints, and
- communicate requirements and prioritization to the tech team.
That’s a good starting point, but I wanted to add a few things to that description that have come out of my conversations with product managers and the people who work with them.
UX is not UI
It’s been said before, but it bears repeating: user experience is not about the interface. It’s about the complete end-to-end experience of engaging with your company and your product. This is the part where the product manager observes the user and designs experiments to gain more insight, so that they can be the voice of and proxy for the user in internal discussions. Lean startup principles and customer development are two ways of thinking about how to collect those data and insights about what drives your customers. The product manager has to collect that qualitative and quantitative data and make sense of it in the form of a product strategy.
The product manager holds the overall vision for the product. That person must be able to guide the fine-tuning of the details without losing sight of the bigger picture of what the company is trying to build. Usually, this involves maintaining a product roadmap for internal communication.1 The goal is to help guide the team in the process of creating a high-quality product that achieves that vision without diluting that value. One of the most difficult parts of the product management role is saying no to good ideas. A lot of good ideas don’t add up to a great product. If you’re having trouble with ideas in isolation, try making it a strategic decision by choosing among choices instead of making a series of binary decisions.
All Together Now
The product manager also has an important role in coordinating between the development, design, marketing, and sales teams, as well as accounting and business development. Each of these groups speaks a different language – with different jargon and different salient variables and goals. The product manager is the ultimate cross-cultural communicator, speaking each language and translating among them. Building consensus and coordinating efforts across functions is critical to executing a strategic plan, and the product manager is responsible not only for coming up with the strategy, but also for seeing it through.
On teams that use Agile, the product manager sometimes serves as the Product Owner, in the role as proxy for the customer or end user. While insights from the true product owner – the user – are key to setting strategy, the product manager is the one inside the building and available to give clear decisions about murky ideas. Those decisions aren’t necessarily always right, but they help the team avoid analysis paralysis.
One note here: the Scrum Master in Agile is the person who owns the Agile process. The product manager cannot effectively serve as the Scrum Master, because those roles have different priorities that often naturally involve some productive conflict, and that should remain a separate role.
As the person who can most clearly articulate the problem you’re trying to solve for your customer, your product manager can be a great evangelist for your company. The fact that she has interactions with and an understanding of almost every part of the business is an added benefit. If you have a product manager who is a good public speaker, take advantage of it and put her out there. You will probably see extra benefits from giving her more time “out of the building.”
Product Manager Job Description
This got me thinking: if I was writing a job description for an exceptional product manager, what would I include? The following is my take on the skills needed to excel in this role. Feel free to commandeer this for your own purposes.
Experience with lean startup and customer development. Understand the customer, and not just by asking them what they want.
Ability to influence without authority. Much of the product management role requires coordinating among people who don’t report directly to them. Diplomacy and negotiation is a requirement, not a nice-to-have.
Previous P&L Responsibility – The product manager must understand business to the degree that he can understand the constraints, risks, and tradeoffs, and make educated bets with imperfect information.
Analytics and data – Qualitative data are great, but even more useful when they are not used in a vacuum.
Coaching technical teams – It’s critical that the product manager has some sense of what is easy and what is difficult for developers. Also required: being able to communicate what you want to the team and predict challenges the team might confront.
Technical Background – When you can speak your developer’s language (if not write it), everything goes smoother because you can skip steps by understanding technical limitations and complexities.
1. The internal caveat here is key. If you publish the roadmap, customers will see it as a promise instead of a flexible plan.