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.
An interview with Agile expert Elliot Susel about using agile to mitigate tech risk.
Teague Hopkins: Welcome. I’m Teague Hopkins. Today I’m here with Elliot Susel, the senior project manager and primary Agile evangelist for Taxi Magic, an app that helps people book ground transportation. Elliot’s an expert on Agile has worked on it for five years at Accenture and now you’re at Taxi Magic. Is that right?
Elliot Susel: That’s right.
Teague: To start off, what is Agile for people who are not familiar with it?
Elliot: The core idea behind Agile is a series of practices that help you to develop software iteratively. That’s the core idea behind the Agile methodology.
Teague: For some of our entrepreneur listeners, how can Agile help ameliorate tech risk, this idea that we’ve talked about as the challenge of whether we can actually build the things that we’re trying to build?
Elliot: As you’re working toward a technical solution there’s a number of tools from the Agile methodology that you can use to help you work iteratively and to work your way toward a solution rather than having some grand vision and being unable to test that vision until you’ve got this final product and it may fall on its face. The idea is that by having value that you can deliver incrementally by using Agile processes and working iteratively you can test your assumptions as you move along and then also refine your ideas. As it relates to technology specifically, there’s a couple things that you can start to accelerate by working iteratively. The first is that not only are you able to improve the product, you’re also able to improve the team that’s working on the product. So, one of the core Agile practices is this idea of a retrospective where the team talks about what’s going well, what’s not going well, and specific actions that we can do to improve in the future.
Teague: I know that you’ve got a couple of retrospectives that you use on a regular basis. Can you explain what your favorite one is and how it works?
Elliot: Yeah. One of the favorite retrospectives that I’ve ever done was oriented towards gaming and I said, we can make this retrospective not just an exercise where we make some columns on a whiteboard and say here’s what we liked, and here’s what we didn’t like, but we could get really creative. So, we turned it into this game where you would draw on the whiteboard anything that would accelerate us, and you would draw on the whiteboard anything that would impede us, and we were represented as a ship in the ocean. We ended up with giant squid, and fire-breathing monsters, and anchors, and airplanes, and sails, and party cakes, and all kinds of representations, and
Teague: And that still helped you get towards the goal you were getting at?
Elliot: Each one was not just a fun thing to draw, but also had with it an association. I think that the giant squid had to do with our testing, and the team then had to figure out well how do we solve this issue of testing and then they also drew something in to deal with the giant squid which was a fun exercise.
Elliot: It kept it light-hearted and it got everyone really engaged.
Teague: Uh huh. (affirmative) It sounds like a lot of this idea of working on the technology in an iterative way sort of dovetails with a lot of the Lean startup methodologies. In your experience have you seen any byplay there?
Elliot: I would say yes and no. You can do Agile without being Lean, which is unfortunate, but I would say that there’s really three roles on an Agile team. One role is the product person, the product owner more formally, where their vision and their goal is to set the vision for the team and define what the team should be building. Now a product owner may or may not be working according to Lean principles and can march the team in a direction that may or may not be consistent with Lean. There’s the scrum master whose job it is to remove impediments and to help the team move as quickly as possible.
Teague: Uh huh. (affirmative)
Elliot: And, the team whose job is ultimately to be in the iteration.
Teague: Uh huh. (affirmative)
Elliot: And the more time they spend in the iteration and not on distractions, the better.
Teague: If you were talking to somebody who’s adopting Agile for the first time or trying to adopt Agile for the first time, what would be the most important piece of advice you can give them in terms of taking their first steps?
Elliot: Find a really good coach. Find the best possible practitioner that you can actually spend time with. And, to use the words of the scrum master and practitioner that I learned from, to spend time in their dojo.
Teague: Uh huh. (affirmative)
Elliot: A scrum master really is creating an environment and it’s not just this series of practices; although the practices are important, but it’s an organizational mindset where yes the team can build incrementally and that’s lovely and that mitigates your tech risk. But, also, it helps if the product team is also thinking incrementally and how can we test our assumptions incrementally, and how can we incrementally work toward our solution in the best possible way?
Teague: Excellent. Well, thanks, Elliot, for joining us today. You can find out more about Agile, and Elliot, and Taxi Magic at Elliot’s website at www.elliotsusel.com. Thanks for listening.
This interview originally appeared in The Three Biggest Risks to Your Startup.
Starting any new venture is risky. Before we can limit or manage the risk, we have to understand it.
Most startup (or new product) risk can be divided into three buckets:
- Tech Risk
- Market Risk
- Ego Risk
Tech risk is what entrepreneurs (or intrapreneurs, for those starting something within an existing structure) most often think about when starting a new venture. Can I build this thing? Is it scalable? Do I have enough servers? The irony is that, especially for consumer web startups, this risk is usually negligible. Most web startups aren’t doing anything that hasn’t been done before, unless it involves patentable algorithms. It may not be easy, but there’s high certainty that it can be done, given sufficient resources.
Market risk is the antithesis of the idea that “if you build it, they will come.” Do people have this problem? If we can deliver the solution, will people even want it? Can we reach the people who will buy this product? Do people believe that our solution is credible? Entrepreneurs should be thinking carefully about market risk.
The final type of risk facing any new venture is ego risk – and it’s probably the most important and the least discussed type of risk. Ego risk is the chance that an entrepreneur can’t get out of her or his own way, pay attention to the data, overcome cognitive biases, and avoid falling prey to a reality distortion field.
With so much risk, it’s a wonder any new venture survives (many of them don’t). But researchers and entrepreneurs have worked hard on each of these types of risks, and there are strategies for ameliorating each one.
Tech Risk + Agile
Tech risk is often mitigated with some implementation of Agile methodologies. I sat down with Agile expert Elliot Susel to ask him how entrepreneurs can get started with Agile. Listen to that interview here: See the Full Transcript.
Market Risk + Lean Startup
Minimizing market risk is the driving force behind much of the lean startup movement. By making a set of small bets in the form of lightweight experiments, entrepreneurs can validate market demand before investing in building a system to deliver a solution or product. Plus, talking to customers often helps entrepreneurs identify problems they had not originally imagined. Sometimes those new problems are more pressing for the customer, and lead to a new product with less market risk.
Ego Risk + ?
Ego risk is the final and most difficult hurdle. There’s no clear-cut answer to this challenge. Religions and philosophers have been focused on ego for millennia. But a meditation or mindfulness practice can be particularly useful in helping us step back from our impulsive reactions to external stimuli (e.g. data that challenges our preconceived notions, particularly if our self-worth is invested in being right, or in one particular self-image.)
Of course, even a zen-master-like separation from the ego doesn’t completely protect us from cognitive biases, nor does a higher IQ or more awareness of these effects. In fact, there is some evidence to suggest a correlation between higher IQ and higher susceptibility to cognitive biases. We don’t yet have any proven methods for overcoming biases, but the Wikipedia page on mitigation is very interesting reading, and a good starting point for learning more.
For more about ego risk and some ways to deal with it, be sure to subscribe to the Innovator’s Digest.
Usually when we talk about risk at a lean startup event, it goes something like this:
There are two types of risk: market risk and technological risk.
Agile methodologies are used to reduce technological risk, and lean startup (and customer development) helps reduce market risk.
The discussion continues when someone adds:
Web startups don’t really have technological risk. We know we can build it. We don’t know if anyone wants it.
Biotech companies typically have tech risk, but no market risk. Everyone wants a cure for cancer, but we don’t know how to build it (yet).
But I found myself in the middle of a very interesting conversation at last week’s DC Lean Startup Circle. We were talking about a third type of risk that is critical for startups, what Ben Willman calls “ego risk.”
From what I’ve seen, the vast majority of people working in startups have a tendency to want our work to be as good as possible before we show it to people. This instinct runs counter to the concept of a Minimum Viable Product.
We all get attached to our clever solutions, sometimes even after we’ve discovered that they solve the wrong problem (or no problem at all). Ego is why we get attached to our solutions and stop questioning, and why we want to avoid customers until it’s perfect. It’s why we conflate our sense of self-worth with the success of our product or startup.
Ben Horowitz (of Andreessen Horowitz) has written that the most difficult skill for CEOs is to manage their own psychology. He also points out that it’s almost taboo to talk about personal psychology. It’s too easy for founders or CEOs to get in their own way and prevent themselves from executing with objectivity and mindfulness.
We talk about the technical and market risks facing a startup. Why don’t we talk about this more important risk? We need to acknowledge and address ego risk.
Startups have tech risk (can we build it?), market risk (will they buy it?), and ego risk (can I get out of my own way?).
If you want to join the conversation, come check out Ben Willman’s presentation on the subject at the next DC Lean Startup Circle.