Project management

Oct 11 2013

The Secrets of Product Management

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.

Vision

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.

Bonus

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.

Double Bonus

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.

Feb 22 2013

Interview with Elliot Susel: Tech Risk + Agile

An interview with Agile expert Elliot Susel about using agile to mitigate tech risk.

Full Transcript

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.

Teague: Great.

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.

Nov 02 2012

The Founding Trio

Dave McClure of 500 Startups calls it the holy trinity of startup founders. The frequent mantra in the startup space is that there are three primary types of founders: hackers, hustlers, and designers. The prevailing wisdom is that you should have one of each of these on your founding team. But we don’t often talk about what constitutes each of these archetypes.

Hackers

Hackers are not simply code monkeys. They need to be able to do more than just code well. Comfort with ambiguity and an understanding for coding in that context is invaluable for the hacker-founder. Many programmers are happier simply building what they’ve been told to build, but the good entrepreneurs are those who think about what happens when the requirements change – and code as if they will. This means building some things quick and dirty, and accepting that there will be some technical debt incurred in favor of rapid iteration.

Communication skills are also critical for hacker-founders. To achieve company success beyond personal success, you need to be able to communicate a vision to other technical team members and to translate for your non-technical co-founders. Likewise, some comfort with project management is valuable. Finally, any good programmer should understand how their outcomes tie to the success of the business. For programmers working for others, this is the way you communicate your worth; for hacker-founders, this is how you prioritize, test, and iterate for your startup.

Hacker-founders are not the only ones who need these skills, but the reality that there is far less supply than demand for excellent technical co-founders may tempt many non-technical folks to overlook these gaps in their search for a technical co-founder. If all you’re looking for is a code monkey, don’t make them a co-founder; just hire them on a contract basis until you can attract someone who has the complete package.

Hustlers

Hustlers are usually the business development specialists in a startup. It is important to note that this is not the same as an “ideas person.” Ideas people are thinkers; hustler-founders are doers. In a startup, anyone who fails to contribute anything beyond ideas is dead weight and should be cut loose at the earliest opportunity. Hustlers are the ones making deals happen, talking to customers or partners, raising funding to extend the runway, and generally removing obstacles for the rest of the team. Hustler-founders need to be resilient in the face of an endless stream of “no” and tireless in their pursuit of opportunities to promote the company.

Designers

When we talk about designer-founders, most people think about web design or mobile app design, but these are not the most important skills. What startups really need is UX designers, not graphic designers. This point gets lost because many designer-founders have both sets of skills. But make no mistake: this role is not about making your product pretty. It’s about making your product enjoyable and effective. Designer-founders should have extensive experience with problem solving and a disciplined approach to understanding the customer’s problem and designing for the customer’s interactions and experiences with the solution.. Designer-founders might approach this task from perspectives including design thinking, lean startup, user experience design, ethnographic research, or some other school of thought. The important part is that the designer-founder focuses on creating an complete end-to-end experience for the customer, not just the gloss that covers it.

A little of column A, a little of column B…

Few roles fit squarely into one of these categories without overlapping with the others, and any early startup employee needs to be prepared to tackle any challenges that arise. However, if your founding team has the right mix of skills to cover each of these three areas, it will give you a better chance of overcoming challenges and ultimately building a sustainable company.