Arriving at a company as a new (or sometimes, the first) Product Manager can be daunting. Product Management is usually introduced in an organization once there is a such a high level of internal enthusiasm and chaos that the leaders aren’t sure how to handle it any more. And then everyone looks to the Product Manager — you — to “manage stuff”.

It’s easy to get overwhelmed by how much there is to do when you step into a stressful role like Product Management. So here are some recommendations on how to spend your first 3 months at a new company.

First 30 days: Understand the product, the market, and the company culture

The goal of the Product Manager is “to deliver measurable business results through product solutions that meet both market needs and company goals”. With that in mind, spend the first 30 days learning and understanding:

• The product. What does the company sell? What does the product do? How does it work? What is the value proposition? What problems does it solve for customers? What features does it have? What kind of bugs does it have? What are the main usability issues?
• The market. Who currently uses the product? What are they like? What are their characteristics? What do they like and not like about the product? Who is the target market? Are there personas for each different type of person in the target market? What are macro and micro market needs addressed by the product? Who are the competitors?
• The current product/market fit. Are you in a good market with a product that can satisfy the market? What are the gaps that you need to close between what the product does, and what the market needs, to ensure a better fit?
• The company culture. Talk to as many people as possible in the organization — from marketing to finance to design to engineering — to understand how things work. What do people like about the product development process? What do they hate? Do designers feel like they have enough time to do their work? Do developers have what they need to program effectively?
• Ensure the PM role is properly understood. For a Product Manager to be effective, the organization needs to understand that PMs should have autonomy over the products they manage. Executive buy-in is a prerequisite for success, so make sure that it’s well understood that even though everyone gets a voice, not everyone gets to decide. As Seth Godin once said, “Nothing is what happens when everyone has to agree.”

Next 30 days: Develop a strategic product plan

Based on what you learn in the first 30 days, start the product planning phase:

• Run a Product Discovery workshop to start identifying user needs, business needs, and technical needs, and to create a problem frame diagram.
• Develop personas and user journeys, and start brainstorming ideas for product development with the team.
• Work with the team to prioritise ideas and start building a roadmap for development. Consider methods like the KJ-technique or the Kano model as a way to formalize prioritization efforts.
• Identify success measures — define how you’ll know if what you’re doing is having the desired impact. The 3 A’s (Acquisition, Activation, Activity) are always a good start.
• Put the appropriate processes in place to ensure effective product development lifecycles. This means knowing what kind of requirements and specifications developers need to start working, how research and design fits into the process, where marketing becomes involved, how QA should work, etc. You can only do this once you understand the current culture, and what the strategic plan will be going forward.

All of the above goes into a document called the strategic product plan. Among other things, this plan includes statements about the product’s value proposition, who the market is (customer profiles), how you plan to achieve product/market fit (the business opportunity, pricing, distribution), what the priorities are, a first stab at the roadmap, and proposed success measures.

Next 30 days: Start executing on the strategic product plan

Now that the plan and the initial roadmap are in place, start the product execution phase:

• Start with a reasonably small requirement with clear and easily measurable success metrics. Work with the team to get it done right.
• Measure, and show the success of the process. Use this to build trust and continue to ship improvements (and even better products).
• Assess the situation, and use customer and business feedback to adjust priorities (and the roadmap) as needed. Flexibility is key.
• Keep going. Repeat any of the initial steps as needed.
• Have fun while you’re doing all of this.

The life of a Product Manager has an exhausting, exhilarating rhythm that is beyond the scope of this article. But spending your first 3 months systematically moving from product planning to product execution will not only give you a solid foundation from which to improve the product, but also ensure that you hit the ground running by shipping the right improvements as early as possible.

I posted an earlier version of this article as an answer on Quora.

Look at your feature roadmap right now. Are there major initiatives and ideas that were generated directly from your designer or design team? If yes, was design in the room when the other items were created and prioritized? Congratulations, you’re design-driven.

— Cap Watkins, Building a Design-Driven Culture

Neil Hunt, Chief Product Officer at Netflix, wrote a good answer on Quora to the question Why doesn’t Netflix offer “Advanced Search” on their site? It’s a great Product Management lesson:

Nothing is purely additive unless everyone uses it. If there’s an affordance to use a feature, the affordance is a distraction to everyone, while the positive value accrues only to the users and potential users. The net value of a feature is the value to the users of the feature, divided by the distraction of the affordance to everyone. Advanced search ends up being used by such a tiny fraction of users (sub 1%), that it can’t possibly pay for its cost.

This is a good way to decide if a feature is worth adding or not. The question isn’t simply “Can we do this?”, or “Will users like it?” The question is, “Will enough people use this feature to make it worth the development and maintenance cost?” In the case of Netflix, the cost/benefit calculation just didn’t work out on Advanced Search, so they wisely decided not to launch the feature. But Neil goes further to say this:

But let me share that what does work well is making simple search deliver the advanced results.

That’s an important point. Advanced Search solves a particular user need, but it solves it in an expensive way. The need doesn’t just go away though, so they spend their development efforts on developing solutions that meet that need for all users, not just those who might have used Advanced Search.

The lesson here is obvious. Instead of implementing features just because other products have it, ask what user needs are met with that feature, and then look for cheaper and/or simpler alternatives to meet those needs. Luke Wroblewski’s New Approaches To Designing Log-In Forms come to mind as a good example of this approach.

Greg McKeown’s The Disciplined Pursuit of Less is an article about careers, but his solid advice also applies to software product development:

If success is a catalyst for failure because it leads to the “undisciplined pursuit of more,” then one simple antidote is the disciplined pursuit of less. Not just haphazardly saying no, but purposefully, deliberately, and strategically eliminating the nonessentials. Not just once a year as part of a planning meeting, but constantly reducing, focusing and simplifying. Not just getting rid of the obvious time wasters, but being willing to cut out really terrific opportunities as well. Few appear to have the courage to live this principle, which may be why it differentiates successful people and organizations from the very successful ones.

Joel Spolsky wrote a great post on some of the hidden costs of software development. From Software Inventory:

The “cost” of code inventory is huge. It might add up to six or twelve months of work that is stuck in the assembly line and not yet in customers’ hands. This could be the difference between having a cutting-edge product (iPhone) or constantly playing catchup (Windows Phone). It’s nearly impossible to get people to buy Windows Phones, even if the iPhone is only six months better. A lot of markets have network effects, and being first has winner-take-all implications. So getting rid of inventory in the development process can make or break a product.

He goes on to propose an alternative to Backlog Grooming — one of the central tenets of Agile development:

The trouble is that 90% of the things in the feature backlog will never get implemented, ever. So every minute you spent writing down, designing, thinking about, or discussing features that are never going to get implemented is just time wasted. When I hear about product teams that regularly have “backlog grooming” sessions, in which they carefully waste a tiny amount of time and mental energy every day or every week thinking about every single feature which will never be implemented, I want to poke my eyes out.

His proposed solution is quite radical from an Agile perspective, and I’m not sure how it would work on large redesign/replatform projects, but it’s certainly worth considering.

If you’re involved in any kind of software development work, I highly recommend the Harvard Business Review article Six Myths of Product Development (it’s paywalled, but keep reading”¦). It details 6 common misconceptions of most product development managers:

1. High utilization of resources will improve performance.
2. Processing work in large batches improves the economics of the development process.
3. Our development plan is great; we just need to stick to it.
4. The sooner the project is started, the sooner it will be finished.
5. The more features we put into a product, the more customers will like it.
6. We will be more successful if we get it right the first time.

The authors detail the effects of and possible solutions to each of these fallacies. Here’s an excerpt from the resource people utilization section:

In both our research and our consulting work, w’ve seen that the vast majority of companies strive to fully employ their product-development resources. The logic seems obvious: Projects take longer when people are not working 100% of the time””and therefore, a busy development organization will be faster and more efficient than one that is not as good at utilizing its people.

But in practice that logic doesn’t hold up. We have seen that projects’ speed, efficiency, and output quality inevitably decrease when managers completely fill the plates of their product-development employees””no matter how skilled those managers may be.

Unfortunately the full article is behind a paywall. You can read the whole thing if you haven’t hit your 3-articles-per-month quota yet (sigh”¦). Or you can download this PDF I made of the print view.

Ryan Singer wrote a very clear and succinct definition of Product Management in Advice for product managers:

“Managing the product” means deciding what we do to the product and then making it happen.

When you unpack that, it involves strategy (what is important to do?), resources (how much time can we spend on it?), managing development (what do we need to build in order to do it?), managing experience (how will it look and work, how does it integrate into what we already have?). And all of it with regard to the bottom line of the business. Given a strategy, resources we have, a user experience bar to uphold ”” given all that, what can we do and why is it worth doing?

It’s a great primer for anyone who wants to understand what PM’s do - especially for people who are considering making a career change to Product Management. There’s one part I’d like to unpack a little more, and that is prioritization. Ryan touches on it as follows in a section entitled “Deciding what to do”:

I try to lead every decision with user experience. What is the user-facing situation we want to change? Or if the motivation isn’t because of a user benefit, but a pure business reason ”” what is the impact on the user, and how can we align incentives so this at minimum makes sense to the user? This is critical.

He advocates for “leading with design”, which is a sentiment I wholeheartedly agree with. But how does this work in practice, particularly in large organizations with a variety of product lines and a gazillion stakeholders? We’ve spent a lot of time trying out different ways to solve the problem of prioritization, so I naturally gravitated towards that section in Ryan’s piece, and hoped for a little more detail. Ryan, if you’re listening - I’d love to see a follow-up post where you explain your process a bit more.

This is important because I believe the hardest part of a Product Manager’s job is answering the strategy question that Ryan uses in his definition: What is important to do? Once you know what to do, the how isn’t necessarily easy, but you’ve at least started the race and you know what you’re running towards. You’ll work with developers to understand technical requirements. You’ll work with designers and guide them through a user-centered design process. Running the race is the fun part. Deciding which race to run is the excruciating part, and it makes or breaks a product.

How others prioritize

There are many established processes for product prioritization, and we’ve tried most of them on the various teams I’ve worked with. I’m particularly interested in methods that can be used on an ongoing (daily/weekly) basis - not ones that are used every few months for long-term planning. The KJ-Method has a lot going for it:

The KJ-Method is a fascinating mix of independent brainstorming, group dynamics, and democracy. It allows a team to be creative and critical in a productive manner, where strong personalities and politics play second fiddle to the independent perspectives and experience of the team.

Jared Spool claims that he can do this process in under an hour with a team, but my theory is that he can only do that because he is superhuman. I find the 8-step process a little too heavy and time-intensive for day-to-day use. It’s great for longer-term strategic planning though.

The Kano Model is another great technique for prioritization:

The easiest way to think of the model is on a two-dimensional grid.

The horizontal axis represents the investment the organization makes. As investment increases, the organization spends more resources on improving the quality or adding new capabilities.

The vertical dimension represents the satisfaction of the user, moving from an extreme negative of frustration to an extreme positive of delight.

As much as I like this model, it suffers the same downside as the KJ-method - it’s too time-intensive for ongoing prioritization. And then there is Amazon’s approach, which is based on the following principle:

Prioritize themes, not projects - Create a list of themes for your product or business. Examples might be customer acquisition, activation, retention, avg revenue per user, avg visits per user, etc. Pick ~3 that are the most important for your product given its stage.

The gist is that they prioritize based on a project’s potential impact vs. cost:

Look for the projects with the greatest projected impact with the least cost, and do these ones first, quickly. Then move on to the next projects, or the next phases of the early projects that had a greater than expected impact.

How we prioritize

I’ve found a stripped-down version of the Amazon method most effective and realistic in our organization. As much as I agree with the principles of each of the three approaches mentioned above, they tend to be unrealistic in the context of ongoing prioritization. So here is the extremely simple process we’ve used on an ongoing basis, with good results:

1. Have a white board with a permanent two-by-two matrix on it. The horizontal axis represents Business impact (which includes user needs and technical considerations), and the vertical axis represents Level of effort to implement (which includes people and their time commitment).
2. Write product requests and ideas on sticky notes as they come up, have a quick discussion with relevant people to ascertain business value and level of effort, and then put the sticky note on the two-by-two matrix.
3. Write prioritization numbers next to each of the features/themes, starting with those that have the highest business value. I like a 70/30 split between high effort / low effort features, but that’s a theory for a different post.
4. Every week or so, check your roadmap to make sure you’re still working on the right things, and make adustments as needed.

It’s a simple method, and it’s far from perfect. But it has a few things going for it:

• It’s detailed enough to ensure constant prioritization based on what’s important.
• It’s light enough to make it practical for everyday use.

PM’s should spend most of their time managing experience and managing development - two of the activities Ryan points out in his post. I’m sure they don’t skip over the prioritization part at 37signals, but I wanted to give some more context around that because it’s something I struggle with a lot, and I guess I hope I’m not alone. Actually, I know I’m not alone. If we all knew what was important to work on, there would be no failed products.

When I arrived at kalahari.com in December 2010 the site hasn’t seen any significant UI improvements during the 10+ years of its existence. My job description was pretty straightforward: do something about that.

In this post I’d like to talk about the work our team did over the past 12 months to get where we are today. When I look at the site now I still see so much wrong with it - there are way too many things that we still need to fix. So this isn’t an attempt to hold up our work as some kind of standard. I’m doing this in the interest of sharing our methods and lessons learned with the larger design community. I’ve learned so much from others who have shared their stories that it seems only fair that I do the same. So here’s our journey so far.

Making sense of the landscape

Here’s what kalahari.com looked like on December 1, 2010:

If you stepped through the site back then you probably would have felt as overwhelmed as I did. Where do we start? What order should we do things in? After the first few days of having too much coffee and talking to people all over the organization I realized that we had two primary challenges:

• No formal prioritization or product development process. It was the same situation I’ve seen many times before. Requirements went straight from “The Business” to developers. That kicked off an endless back and forth about what was needed, with only a cursory nod to Design. The “First In First Out” approach to prioritization was also quite common. The result was, well, not ideal. We needed to fix this.
• No formal user experience design. This was no surprise, and it was the reason I took the job in the first place. There was no user research, no content strategy, no interaction design, and no visual design beyond marketing and merchandizing materials. This is the part that really excited me: the opportunity to introduce User Experience Design into an organization that was (to their enormous credit) hungry for it but didn’t know where to start.

So we immediately got to work on both those problems.

Hello, I’m a Product Manager

Introducing a Product Management layer into an organization that’s used to working without it is tricky. If you do it wrong it can become a political nightmare and end up ruining your chances of shipping anything good. You might have the best of intentions, but there is always the danger that the only thing people will think when they look at a Product Manager is, “Hey, I used to be responsible for that, jackass!”

We certainly didn’t make this transition perfectly, but I believe the key is to make sure that you talk to as many people as possible about what their organizational issues are, and how they think it can be done better. You have to take the time to explain the benefits of having a Product Team that takes responsible for strategy, vision, and execution of a product (and takes the fall if it fails). And then, most importantly, you have to make the development process fair[1].

We now have a team of Product Managers who are responsible for delivering measurable business results through product solutions that meet both market needs and company goals. They work closely with their teams to develop the strategy and vision for their products. They ensure that designers and developers are included throughout the process. And most importantly: they make sure we ship.

The Intergalactic Product Force

One concept we introduced that I think is worth talking about is the Product Council[2] - a formalized way to deal with prioritization.

The Product Council is made up of the heads (VPs) of every department in the organization: Engineering, Marketing, Support, Category, etc. We have a weekly meeting where we discuss the current product roadmap and priorities. We ask ourselves, Are we still working on the most important things? If something more important comes up, we prioritize it higher in the roadmap, and something else shifts down. If w’re happy with the direction, we do nothing. If a new opportunity arises we ask ourselves, Is this more important than what w’re working on right now? Or is this something we should work on next? If so, what moves down in the priority list?

From here, I communicate any changes to the Product Team, and we discuss this to make sure no one missed anything. But then — and this is important — the Product Manager has complete autonomy and ownership over the implementation of his or her roadmap. The Product Council sets the priorities (with input from all parts of the organization), but the Product Managers work with their development teams (and others) to set the timeline, the implementation details, the design, everything.

Ther’s more to it, but in the interest of brevity I’ll stop there. This process has three main advantages:

• It gives the management team complete transparency into what the Product team is working on, and it allows for anyone to make the case for a change in priorities. Why this kind of transparency is so essential is a subject for a different blog post, but in short, it takes away a vast majority of the politics you see in many organizations, and it frees up the teams to do what they do best — execute.
• It prevents scope creep. Nothing can go on the roadmap without something else moving out or down. As anyone who ever worked at a large organization knows, this is an absolutely critical part of a successful development cycle.
• It gives the Product Manager and their teams what they need to be successful: direction and autonomy. As Jocelyn Glei says: “Give your team members what they need to thrive, and then get out of the way.”

Hello, I’m a User Experience Designer

I knew that we needed to build a great team if we were going to follow a user-centered approach to identifying and addressing the main issues on the kalahari.com site. But building a team takes time and money, and it’s hard to justify a large headcount request before you’ve proven that you can have a real impact on the business.

So we started small. I fulfilled the UX Design role, and we hired one visual designer since that was the primary need at that stage. Then we got stuck in. On a site of this size, and with the pressure we had to make improvements quickly, we decided on a dual approach:

• Make some initial and obvious changes to the visual design to improve hierarchy and the general aesthetic.
• At the same time, work on a long-term UX strategy to address some of the more fundamental user experience issues on the site.

The goal was to show quickly that we know what we are doing, and then use those successes to build out the team further and attack the areas where we can have the biggest effect on conversion rates.

Building a roadmap

We started this process with a small team of three Product Managers and two Designers, so we didn’t initially have the luxury of user research and a long period of product discovery to build out a roadmap. Instead, we went offsite for a day and built a customer experience map for our different user journeys. It was a great way to focus on what the core experience is that we need to improve.

We also went a bit further. Based on a heuristic evaluation of the site we annotated each of the steps in the user journey with obvious improvements we could make. This gave us a flexible framework for the year, and guided our roadmap throughout.

We decided early on to realign, not redesign. Our approach was to make relentless incremental progress as opposed to doing a 6-9 month project with a big bang release[3]. Our goal was to release every 3-4 weeks, depending on the size of the project.

In our first two releases we took care of some basics. I won’t bore you with the whole list, but here are the highlights:

• Released a new header and footer.
• Shifted from heavy reliance on orange to a more muted color scheme that allows products to draw more attention.
• Removed several links in the header and footer that didn’t get much use.
• Increased the visual hierarchy of Search.
• Decreased the visual hierarchy of several non-important features.
• Introduced a formal button strategy (primary=orange, secondary=silver).
• Moved from liquid width to a 960px 16-column fixed width design (including the ability to do single-column or two-column designs - every page used to be three columns).
• Started to separate CSS from HTML (better late than never, right?).
• Started to build a UI component library.

These changes had exactly the desired effect. User response was immediate and universally positive. In combination with some good specials, traffic started to increase. And most importantly: we were able to start growing our team to add designers, a researcher, and a front-end developer. Game on.

We spent the rest of the year systematically working through our customer experience map, starting with the most important areas where improved UX can have the biggest effects (Registration, Checkout, Product Details Page, etc.). Our process grew organically and ended up hitting a good stride towards the middle of the year:

• Define the area we’re working on, and define what success looks like (what are the metrics we’re trying to improve?).
• Work in small teams of PM’s, Designers, and Developers to sketch out new flows and develop wireframes.
• Test wireframes with users, utilizing the RITE method so that the outcome is improved designs, not PowerPoint decks with recommendations.
• Refine the designs as they evolve into high-fidelity visual designs (with more user testing as required), and deliver high quality HTML and CSS as the final output.

The outcome is a site that is drastically different from where we were a year ago, with real improvements in the success metrics we set for ourselves (% conversion on registration, checkout, and other flows). The changes include not just the main site, but also a brand new mobile-optimized version, as well as some significant changes to our Marketplace for 3rd party sellers. Here’s just one sample of our Checkout redesign, including one of the initial wireframes[4].

Old Checkout:

New Checkout:

Initial wireframe:

Final design:

Three more things

My biggest regret about this year is that we couldn’t do more. We made some great improvements to the site, but it is still so far from where it needs to be. And I know everyone on the team feels this way. We set out to build a culture of quality above all else, and it physically hurts when you have to make compromises and do something that’s counter to that culture. Before you jump in and say that there’s never an excuse to compromise, let me remind you of something Erin Kissane said in What I Learned About the Web in 2011:

If a single idea has followed me around this year, from politics to art and work to friendships, it’s been this one: “it’s more complicated than that.”

It’s centrally important to seek simplicity, and especially to avoid making things hard to use or understand. But if we want to make things that are usefully simple without being truncated or simplistic, we have to recognize and respect complexity — both in the design problems we address, and in the way we do our work.

So, yes, I agree with you - you should never compromise on quality. But it’s complicated. You sometimes run into technical and business complexities that force you to say, “We’ll have to do this later.” It sucks, but that’s life.

I’m exiting this year with three major takeaways - lessons learned and re-learned through our successes and failures:

• Love your developers. Too many companies see their developers as “resources” whose only reason for existence is to make The Codes. When you pull developers into product planning and design, everything changes. You build better products, and everyone has more fun.
• User Experience Design is a real thing. I saw way too many dismissive comments about UX this year. If you do it right, it will improve conversion rates and/or make more money. If you don’t believe me, come sign an NDA and I’ll show you our metrics.
• Culture is everything. In one story out of the Steve Jobs biography, Bud Tribble (one of the Macintosh team members) is quoted as saying, “Hey, if w’re going to make things in our lives, we might as well make them beautiful.” You need a team that has a relentless focus on quality. A team that cares enough to fight for moving that button 3px to the left. It’s the only way to find real meaning in your work.

We have a lot of work to do on our site (sorry, did I mention that already?). But I’m happy that we’ve been able to introduce a fair and effective product development process into the organization. We made user experience an intricate part of how we build product. And we now have a 14-person team of brilliant and dedicated Product Managers and User Experience Designers who care deeply about the product.

It was a good year.

---

1. I wrote more about this in The most important characteristic of a good Product Manager  â†©
2. No one liked my “Intergalactic Product Force” suggestion â†©
3. I wrote more about this for Smashing Magazine in The Data-Pixel Approach To Improving User Experience  â†©
4. I’ll spend some time over the break putting together some more before-and-after shots, including stories about the process we followed (if anyone is interested) ↩

Over on the 37signals blog they just reposted an old article entitled Product roadmaps are dangerous. Jason Fried says the following:

Instead of the roadmap, just look out a few weeks at a time. Work on the next most important thing. What’s the point of a long list when you can’t work on everything at once anyway? Finish what’s important now and then figure out what’s important next. One step at a time.

It’s hard to disagree with a person (and a company) you have great admiration for, as I do for Jason and 37signals. But I do think it’s important to set the record straight on product roadmaps - particularly when it comes to large organizations. The post highlights two main concerns with product roadmaps:

• Product roadmaps assume you know what’s going to happen 6 - 18 months from now
• Product roadmaps set expectations, so you can’t change them (and if you do change them it becomes a worthless exercise)

So let’s look at each of these points in turn.

Product roadmaps assume you know the future

Jason writes:

When you let a product roadmap guide you you let the past drive the future. You’re saying “6 months ago I knew what 18 months from now would look like.” You’re saying “I’m not going to pay attention to now, I’m going to pay attention to then.” You’re saying “I should be working at the Psychic Friends Network.”

This is not what a product roadmap is, or what it’s supposed to do. The purpose of a product roadmap is to set forth a long-term vision for the business, and break that up into smaller, meaningful pieces of work, based on what you know now. It’s fallacy to believe that this is an unchangeable list of dates about where the business is headed. A product roadmap that doesn’t react to day-to-day changes in the market and within the company is a pretty dumb document.

At my organization we are very clear that the product roadmap is a flexible guideline that can (and must) change frequently as needed. But it gives the teams (and the management team) something to work towards. It’s a common vision, a sense of direction that’s more than just fluffy language - it’s concrete evidence that we’re headed somewhere good, and we know how to get there.

We can change direction as many times as we want. This doesn’t make it a useless exercise, it means that instead of starting fresh on a new “roadmap” every few weeks, you build on your past successes, don’t make the same mistakes twice, and keep making measurable progress since you can see where you came from.

Product roadmaps set the wrong expectations

Elsewhere in the post:

The other problem with roadmaps is the expectations game. People expect you to deliver what you say you will in 4, 5, 6 months. And what if you have a better idea? What if ther’s a shift in the market that you need to address? What if what you thought wasn’t what actually happened? Any change in the roadmap nullifies the roadmap. Then the map isn’t a map at all.

If you have this problem it doesn’t mean that product roadmaps are wrong, it means that you’re doing it wrong. As long as everyone in the organization buys into the fluid nature of the roadmap, you won’t have this problem. In our organization we do this mainly through the mechanism of what we call the Product Council (I was partial to Intergalactic Product Force, but for some reason that didn’t fly so well). Here’s how it works.

The Product Council is made up of the heads (VPs) of every department in the organization: Engineering, Marketing, Support, Category, etc. This body has a weekly meeting where we discuss the current product roadmap and priorities. We ask ourselves, Are we still working on the most important things? If something more important comes up, we prioritize it higher in the roadmap, and something else shifts down. If we’re happy with the direction, we do nothing. If a new opportunity arises we ask ourselves, Is this more important than what we’re working on right now? Or is this something we should work on next? If so, what moves down in the priority list?

From here, I communicate with my Product Team about any changes, and we discuss this to make sure no one missed anything. But then - and this is important - the Product Manager has complete autonomy and ownership over the implementation of the roadmap. The Product Council sets the priorities (with input from all parts of the organization), but the Product Managers work with their development teams (and others) to set the timeline, the implementation details, the design, everything.

There’s more to it, but in the interest of brevity I’ll stop there. This process has three main advantages:

• It gives the management team complete transparency into what the Product team is working on, and it allows for anyone to make the case for a change in priorities. Why this kind of transparency is so essential is a subject for a different blog post, but in short, it takes away a vast majority of the politics you see in many organizations, and it frees up the teams to do what they do best - execute.
• It prevents scope creep. Nothing can go on the roadmap without something else moving out or down. As anyone who ever worked at a large organization knows, this is an absolutely critical part of a successful development cycle.
• It gives the Product Manager and their teams what they need to be successful: direction and autonomy. As Jocelyn Glei says: “Give your team members what they need to thrive, and then get out of the way.”

Why product roadmaps are safe (and essential)

At a practical level I went through the exercise of figuring out how we could execute in my organization without a roadmap. And I just can’t see it. Changes to current pages/flows affect changes we’ll make down the line - I have to think about that.

If you’re serious about frequent incremental change as opposed to large redesign projects (as we are), you can’t live without a roadmap because you’ll have no idea how far you’ve gone, what you still need to do, and what’s more important than something else. And perhaps most dangerous of all, everyone in the organization will come to you and want all their projects done right now, and you’ll have no systemic method for dealing with that in a way that’s best for the business.

Andy Wagner summed up my feelings on this issue quite succinctly in a comment on the 37signals post:

[Product roadmaps are] an opportunity to dream about what the future might look like so that as you make your day-to-day responses to the customer, you can do so consistent with building the future state. It emphatically should not be anything to be slave to, it should be dynamic and notional, not static and specific.

Jason says, “The further you get from now, the less you know. And the less you know, the worse your decisions will be.” We agree on that. My argument is that without a roadmap you only see now. And if you only see now without seeing yesterday and tomorrow, you don’t see a whole lot. And “the less you know, the worse your decisions will be”.

About a week ago I had a discussion with a colleague in our development team about the new product development process we rolled out a few months ago. One of the words he used to describe the new process is fair.

It was a passing comment and I didn’t really think much of it at the time, but since then I keep going back to that conversation, and the importance of fairness in the product management profession.

Loads of articles have already been written about the characteristics of a good Product Manager (see the end of this post for links to some of them). They’re all fantastic, and I go back to them constantly when I’m in the hiring process or looking for personal development areas. But I’ve never been able to find the one characteristic that I think a PM simply cannot do without. I now think that fairness is that characteristic. Here’s why.

The role of fairness in effective product management

Let’s look at one definition of the word fair:

fair. adjective. free from favoritism or self-interest or bias or deception.

Free from favoritism

One of the fastest ways to become ineffective in a PM organisation is to start playing favorites with a particular internal group, product line, or user base. As soon as people sense that you are not looking at all ideas and input equally and fairly, a lack of trust inevitably follows. And without trust, you’ll have to work a lot harder (and longer) to bring people along for the ride on your roadmap.

Free from self-interest

If you start doing things purely with reasons like “because I want to” or “because I’m being measured by this metric,” that same lack of trust happens very quickly. You cannot be effective by nursing your own pet projects and ignoring all the other needs around you.

Free from bias

This often happens when PM’s get news they don’t want to hear — especially from the user research team. If something doesn’t test well, don’t make up reasons why you are right and the users are wrong. Do the right thing and realign the design.

One of the hardest skills for a PM to learn is to take their own emotions and feelings out of the equation when it comes to decision making. Yes, a lot of gut feel goes into a product vision, but that cannot be based on personal preferences or preconceived ideas.

Free from deception

This one seems obvious, but you see it often, especially when it comes to metrics and assessment. Don’t ignore/distort negative data or make a problem someone else’s fault. The PM’s job is to own a product — and this means owning its successes and its failures. You’ll gain trust and respect if you not only claim the successes, but also acknowledge the failures and commit to do it better next time.

The elements of fairness in product development

The PM role is often referred to as “the great diplomat,” and with good reason. It is our responsibility to balance a variety of needs from inside and outside the business, and somehow turn that into a roadmap that delivers business value as well as meets user needs. A focus on fairness accomplishes that goal:

• Fairness to users. Approach users with respect, openness and transparency. Understand their needs, and explain to them when you’re doing something that makes it more difficult for them to meet those needs. (Don’t be like Twitter and hide behind reasons like “consistent user experience.”)
• Fairness to the business. Do everything you can to understand the needs of marketing, merchandising, customer support, etc. Pull them into the planning process, be clear about how projects are prioritised, and help them adjust to that process so that they can define their project goals in the right way to get on the roadmap.
• Fairness to technology. Don’t force the development team to make the technology do things it’s not capable of doing. Understand the technical debt in the organisation, and work actively to make those improvements part of regular development cycles.

A lot of this comes naturally in good product managers, but we need to be conscious of it every day. Fairness is a table stakes characteristic for an effective product manager. If you do it right, the real work of building great product can begin. But if you don’t, you’re dead in the water, working with a team that has no reason to trust that you’re doing the right thing.

More characteristics of good product managers:

• Recruiting Product Managers
• The desirable characteristics of a Product Owner
• Owning an Agile Product