Product Managers are awesome! They keep goals in mind and priorities at the forefront –
and when designers get to work with them, it’s a real treat. Clearly, there is a lot of overlap in skill sets, but sometimes you’ll find yourself on a team without a dedicated PM. So if you’re a designer in a position where you need to do a little PM’ing – you’ll want to have these skills.

For a primer on what a Product Manager is and does on an Agile team, check out this great resource. The role is a bit tricky – and as a designer, the work can feel uncomfortable at first because PM deliverables can seem much less concrete than design’s. But, if you can master the secret art of Product Management, you will be a much better designer for it.

Ok, let’s get started.

Facilitation

A cornerstone of any great “Product Person” is an effective, engaging, and personalized facilitation style that can get you through any sticky situation. Here are some of the go-to activities that require expert facilitation. We incorporate all of these into each project we do:

Retros

IPM/Sprint Planning

Workshops

Presentations

Product Vision

At most companies, it is the job of the Product Manager to create and communicate the vision for the product. That doesn’t mean they go sit in a room and imagine something, then make other people build it.

The vision is built on a deep understanding of underlying user problems, business needs and (unless the PM is also the founder) the vision of the leadership team. For that vision to get anywhere near implementation, the PM has to get buy-in from all kinds of stakeholders. Once that’s done, they have to communicate the (revised, tweaked, improved) vision to the team that will help them execute.

There are no shortcuts for this work, and the techniques used come from general management rather than product specifically. Some tools that might come in handy if you’re selling a vision include:

Stakeholder Mapping

A Comms Plan

A Good Story

Product Strategy

Helping shape product strategy is a key skill, and also one of those “what the F@$# does that mean?” terms. There’s a lot of confusion about this, and if you want to know more I suggest you read this book. For our purposes, I think it can be broken down into:

Lean Canvas

Competitive and Market Research

Analytics

Launch Strategy

Product Definition

Product Definition is probably what you are most familiar with. As designers, we are usually deeply involved with what sort of features are in the product, and how those features relate to a user need. While Product Managers think about those things too, they also have a few things in the definition process that are not a part of the the typical design process. The list below reflects both of these.

Brainstorming and Iteration

Prioritization

Product Road Maps

Experience Mapping

Story Mapping

User Testing and Research

Feature Definition

Working with Developers

Product Managers are always faced with tough questions from Developers like “Why are we building this?”, “Do we really need this feature now?”, or “Are you sure we need to rebuild Google calendar?”. Being able to communicate product and business needs to the people who are on the ground creating the product is super important. But, if you want to talk the talk you also have to walk the walk. You should be informed about:

Story Writing

Technical Research

Experimentation

Working with Teams

Product Managers are always thinking about how their team is feeling and how effective it is being. Team responsibility and its productivity has fallen on them, and they are often called upon to motivate and support designers, developers and any other disciplines that touch the product. At Carbon Five, we have learned a lot about working with teams. As consultants, we are not only working with new clients every few months, but also different teams inside Carbon Fiv. Here are a few things we have found helpful.

The Product Dartboard

Psychological Safety

Forming, Storming, Norming, Performing

Conclusion

To sum up: when faced with a challenge, designers are used to getting scrappy and solving problems, much like Product Managers. Understanding the tools PMs use to solve problems can not only help you work with Product Managers better, but can also help you find solutions to your own design problems. Every designer has their own tool box – these are simply tools you can add to it.

If I mention the word “agile” to you, a couple of rituals common to agile methodologies probably come to mind. Daily stand-ups and iteration planning probably top the list, and you probably think of other agile concepts like user stories and estimating their complexity with an arbitrary number of points. Continue reading …

We <3 Prioritizing

In modern software processes, prioritization is at the core of what we do.

We prioritize because we don’t like waste. Waste:

• Of human effort, which is disrespectful.
• Of money.
• Of time.

If you’re wasting one of them, you’re probably wasting all of them.

Prioritizing is variously simple, complicated, demanding, exhausting, and strangely emotional.

In this series, we introduce some tools and strategies that can help you successfully navigate prioritization on your product, at every level and every phase of product definition and development. Continue reading …

We <3 Prioritizing

In modern software processes, prioritization is at the core of what we do.

We prioritize because we don’t like waste. Waste:

• Of human effort, which is disrespectful.
• Of money.
• Of time.

If you’re wasting one of them, you’re probably wasting all of them.

Prioritizing is variously simple, complicated, demanding, exhausting, and strangely emotional.

In this series, we introduce some tools that can help you successfully navigate prioritization on your product, at every level and every phase of product definition and development. Continue reading …

In a discussion about prioritization among product managers at C5, we were in consensus that a 2×2 is a powerful tool in many prioritization scenarios from assessing risks to the product or business to working out the path forward when faced with competing priorities for a product.

As a visualization tool, a 2×2 gets the team on the same page to externalize relative risks or priorities and work through next steps. When things seem murky or like everyone isn’t giving the same weight to particular options, try out a 2×2. Continue reading …

I asked a group of fellow product managers if they’ve ever read through the Agile Manifesto with product owners / clients. They all said “no”, and the general consensus was that doing so wouldn’t be well received. This is interesting. Even though Carbon Five is well-respected for our process, and we definitely practice agile, we’re guarded about discussing it. Continue reading …

We just received our copies of O’Reilly’s latest Product Management title, Product Management in Practice: A Real-World Guide to the Key Connective Role of the 21st Century, by Matt LeMay.
Continue reading …

Carbon Five was recently brought in to build a new product with a planned budget of 6 months. As the first step, we conducted a few rounds of customer development to try and validate the concept. After a month of experiments by a product manager and designer, we ultimately recommended that the company not pursue the idea. Our client spent a few weeks of consulting fees but saved more than 90% of their budget by not building anything.

The client for this project provides software to a niche set of businesses. As more and more competition started popping up, they believed they saw an opportunity to create a digital marketplace in their niche. Before Carbon Five started building software, the client wanted us to confirm demand for the marketplace.

Continue reading …

The tech scene (especially in the Bay Area) has reached a point where it’s expanded way past techies. It seems successful people from all different industries are drawn to the promise, reach, and money in tech. Doctors, bankers, artists, and even educators are launching startups and talking about MVPs. It’s definitely exciting and inspires me everyday. But, building a great product is sometimes more of an art than a science, and first time founders make common mistakes. From a company that has worked with more startups than it can count, and has seen its fair share of first time product mistakes, here are some of the most common ones to avoid.

Continue reading …

As a full-stack software consultancy, we at Carbon Five get lots of questions from clients past, present, and future. We’re passionate about sharing our industry knowledge, so we sat down with our leadership team and got some advice for aspiring founders and product leaders as part of an ongoing 6-part series. You can see all the interviews here.

How healthy is my codebase? Can I rewrite it, or can it be nursed back to health?

A hundred percent of the time, your codebase can be nursed back to health. In my experience, ninety-five percent of the time, that’s the path you should take. This is making one assumption, that there’s a product already built and in use. The bigger the codebase, and the longer it’s lived, the more likely that it has features or bugs or whatever, pieces of code that are in use, that people are relying on, but nobody knows about at the company. So whenever you talk about rewriting a codebase to be the same as an existing codebase, you are opening yourself up for a world of pain because it’s very likely that there’s nobody in the world that exists who knows all of the requirements. If you ever decide to rewrite a codebase, you have to start from first principles and say, “We have to start from the very beginning and define what this new product does, and as a basis, we’re going to use this old product, and we’re going to say this is our starting point.” The same way if a client came to us with wire frames and said, “This is what I want,” we’d say, “Well, we’re going to use this as a starting point, but we’re still going to go through our personas exercise, and our experience map, and our story mapping, and our story writing, because we need to understand all that in order to build this product.” If you can do it that way, then rewriting is actually completely doable. I’ve discovered that even though it can be a lot of work to nurse a codebase back to health, if the functionality is there and fulfilling the needs of the users, then to continue to fulfill the need of the users without any interruption, you gotta nurse it back to health.

A hundred percent of the time, your codebase can be nursed back to health. In my experience, ninety-five percent of the time, that’s the path you should take. This is making one assumption, that there’s a product already built and in use.

Continue reading …