As a product manager I know and understand the importance of making customers part of the product development process through research and interviews. Especially those of us who come from a design background have this philosophy deeply engrained. We know that “I am not the user” and we have the t-shirts to prove it! So it is with some surprise that I recently realized that sometimes — when the circumstances are conducive to it — it’s ok to trust our instincts and create products and features without talking to customers directly about it first.

See, the thing is, talking to customers isn’t something we do, it’s something we are. And if it’s something we are — if we really are immersed in our customers’ needs and behaviors and emotions — we should feel comfortable to trust our own instincts a little bit more.

With this kind of immersion comes an ability to channel our customers in a way that drastically reduces the additional benefit we might get from interviewing them about a specific issue or feature. When we not only have the knowledge of the domains we work in, but also a good understanding of how our customers navigate those domains, we end up with a powerful foundation to base our decisions on.

Does this mean we don’t need research? Of course not! But it means that maybe we don’t need to go out and interview users every time we make a product change or introduce a new feature. It means maybe we do usability testing on major changes to the site, but not when we fix something that we’ve lived and breathed with our customers for months or years.

Those are weird sentences to write. I am a big proponent of User-Centered Design, and obviously research is a central component of that. But what I’m advocating for isn’t less research. I’m saying that it’s possible to reduce the amount of structured research you do, if you have a culture of customer immersion in everything you do.

Customer immersion isn’t an easy culture to create, but it is very much worth it. As a start, everyone in the organization should be encouraged and empowered to talk to customers — whether that is through phone calls, support cases, conferences, or any other way you might be able to reach them. And since not everyone will be able to spend an equal amount of time with customers, it also means you have to listen to those who do spend a lot of time with them — and trust that they are acting as good conduits for customers’ needs.

Making the right choices about when to do structured research and when to trust your (informed) instincts will save you time and money — and make customers happy too. That’s not a bad combination of benefits.

Questionable use of stock photography aside, Colin Lernell’s Is the Product Requirements Document Dead? A Debate. brings up some interesting points. I’ve long argued that if you do it right, a good “product spec” is essential to successful product management and development. We’ve come a long way since the original concept of a 45-page PRD that no one reads (not even the person who wrote it). The format has evolved as we’ve grown accustomed to leaner development processes.

One of Colin’s suggested alternatives to the dreaded PRD is what he calls an MVPRD. I don’t like the term (the overuse of the MVP concept makes it all but useless these days). But the approach is one I agree with:

Write your first MVPRD in a short, limited amount of time (just enough to communicate to your team and start work) to avoid bloat. As you move toward or through development, meet with your team frequently to assess and iterate on what should go into the document and what should be taken out. Remember to keep it lean and that your intent is to figure out what you need in the document and if you need it at all.

Our product specs at Postmark follow a similar journey. At the beginning of a project I start a new spec document from a template in our wiki. I fill out as much of the basics as possible, which in our case consists of the following:

• Basic metadata like who the team is, links to technical specs, etc.
• The job story.
• A stripped down version of Marty Cagan’s Product Opportunity Assessment framework.
• Known dependencies and risks (such as customer support and back-office systems).

We use that information for our team kick-off call, and then we start filling out the rest of the document as we go. We also go back and make changes as we get further down the road and make decisions. We have three main sections for this part of the document:

• The solution overview provides a broad description of how we intend to solve the problem we identified in the Product Opportunity Assessment
• Sketches, Wireframes, and Prototypes links to the the initial design assets we create, in whatever fidelity is right for the size and scope of the project
• Final design has the final assets that are needed for implementation. In our case this is most often a completed front-end.

The important thing to remember about this fluid version of a product spec is that it is not a document you write from front to back at the beginning of a project and then never look at again. It’s also not something that’s every really done. It’s a document that starts small and that you keep working on as you go.

The benefits of doing it this way is that it not only helps you document all the little decisions you make along the way as you build a product, it also builds up organizational knowledge to remind you of why the team made the decisions they made. Because you will forget otherwise. So if you’re developing without a blueprint and feeling some pain and chaos, give this approach a shot. It might just provide the relief you need.

There is essentially two ways to improve at your job. You either get better at the things you should be doing, or you learn to stop doing the things you shouldn’t be doing. We tend to spend a lot of time and effort on the first aspect—and for good reason. It’s absolutely essential to keep learning. But lately I’ve been consumed with that second part. Day in and day out, at the most inconvenient times, the same question jumped into my head:

What are the biggest mistakes I’ve been making as a product manager, and how do I stop doing those things?

I took some strange detours trying to answer that question. And in the end, the answer I came up with specifically for product management had its origin in an unlikely place: some graduate work I did almost two decades ago. So let’s take a quick detour into information science theory before we return to the matter at hand…

---

One of the first things you learn about knowledge management is what’s called the DIKW pyramid. It provides a model for thinking about the transformation of raw data into something more useful.

• Data refers to facts and observations. They are the spreadsheets and SQL query outputs that come across our desks on an almost daily basis.
• Information is inferred from data, and distinguishes itself from data in that it is actually useful for decisions or action. Company dashboards with business metrics like MAUs are information.
• Knowledge refers to a framework for decision-making based on information, i.e. “we believe that when this happens, we should do something about it”.
• Wisdom is illusive—both in definition and in… well, attaining it. I’ve always liked the definition that says wisdom is knowledge with judgment. Wisdom goes beyond having a framework for what to do, and describes having the judgment required to make the right decisions based on the information and knowledge available.

The model isn’t perfect, but it serves a valuable purpose. There are two aspects in particular that I’ve always found useful to remember.

First, to extract value from data it needs to be transformed into something more valuable, and you don’t get to skip phases. If, for example, you try to go straight from data to knowledge without first organizing the data as information, your knowledge isn’t going to be all that accurate.

Second, confusing one slice of the pyramid for another can be really dangerous. If, for example, you’ve been able to extract some knowledge from information, but you think you’re looking at wisdom, you’re going to make some bad decisions, because you haven’t taken the time to add the necessary judgment to the information in front of you.

---

With that as background, let’s get back to product management. If I think about the times when I’ve made my biggest mistakes as a product manager, it can all be traced back to one of two causes:

• I misidentified data, information, knowledge, or wisdom. For example, if someone on the team who is steeped in our product and its users comes forward with a wise suggestion about where to take the product next, and I jump in with a process to take what I think is some information they provided and turn it into knowledge, I’m operating at the wrong level. Turning information into knowledge is essential, of course (remember, you can’t skip steps). But trying to pull wisdom back to an earlier phase in the transformation process is disruptive and demoralizing. We shouldn’t do that.
• I communicated the wrong slice of the DIKW pyramid to the person or team I was speaking to. For example, let’s say a designer and I go through an extensive usability testing process on a prototype of a new feature. We collect data, we group that data into information, and then we discuss it to extract the knowledge and wisdom we need to make the appropriate changes to the product. The difficult part is knowing what to communicate to who. For some on the team, the end product (the “wisdom”) is good enough. Others, particularly those with good data transformation skills, might prefer to see all the information so that they can give feedback on the knowledge and wisdom we landed on. We need to know the difference of what’s needed by who, and share appropriately.

Knowing the mistakes you tend to make is only half the battle, though. So all of this led me to a statement I’m printing out and putting up above my desk, to help me avoid making those mistakes:

An effective product manager shepherds data from a variety of sources through the transformation of becoming information and knowledge and wisdom. They do so without getting bogged down in unnecessary process, and they only share the relevant parts that each person or team needs to make progress.

I’m sharing this here with the hope that it will resonate with some of you who may have been grappling with the same questions.

There’s one more important point I want to make. From my personal life I know the dangers of wallowing in introspection for too long, so I don’t intend to stay down here in mistakes-land. Wrestling with these questions was a helpful exercise, but it’s not a place I want to get stuck in. So I’m going to head out to that other place for now. You know, the one where we get to learn new things and improve our skills. Maybe we’ll see each other on the road.

I want to tell you a quick story about running. And I know it’s a little weird to make everyday life stories about product design but I can’t help myself, so I’m going to do that at the end. Let’s be cool about it, ok?

So.

I hate running. I’ve always hated running. A couple of weeks ago my friend Jason came over for a visit and started asking me about it. He wouldn’t let up. Bastard kept pressing. “Why do you hate running so much?” Over and over and over. Eventually we narrowed it down to breathing. I’ve always felt uncomfortably out of breath when I run. This is when my wife joined the party, and feeding off each other, they kept at it.

What felt like hours later, through their incessant questioning, we figured out that I’ve been breathing ridiculously wrong during my runs for two decades. For reasons that I am unable to explain, I’ve always timed my in-and-out breathing with every third step. Not second. Not fourth. THIRD. The result is that I’ve basically been hyperventilating through my runs for the better part of 20 years.

Anyway, they coached me for about five minutes on how to breathe. Turns out — and this is going to blow your mind — your body knows when it has to breathe. All you have to do is stop trying to force some kind of rhythm. Just focus on getting as much oxygen into your lungs as you possibly can, and then letting it out slowly. Your body will find its own rhythm.

The next day I tried out this revolutionary breathing mechanism. Not only was it enjoyable, I ran faster and further than usual. Last weekend, not even two weeks after they accosted me, I went for a 10k run. It was my fastest 10k ever, and more importantly, I enjoyed it.

I keep switching back and forth between being really pissed that I’ve been doing it wrong for so long, and ecstatic that I’ve been able to figure out the issue. I’m still blown away that a change in breathing can have such an immediate and enormous impact. Mostly, I’m thankful for my friend and my wife, who persisted way past the point of annoyance, and gave me a new lease on running (and, not to be dramatic, but life too).

Here’s where we get to the product design bit. This experience taught me another lesson, something that’s already deeply ingrained but I still forget it sometimes:

You cannot come up with a good solution before you understand the problem completely.

I tried that shortcut with the running thing. I switched up the cadence, or tried to just “break through the wall”. It wasn’t until someone pushed me to get to the cause of it all that we were able to find the right solution. So I resolved to be just a little more annoying at work. All it really comes down to is asking Why? a few more times than I think I should. I know that the answers will help us understand what we’re trying to accomplish, and building a better product for our customers.

There’s a lot you need to get right when launching a new product. There’s figuring out the user needs and the business goals; there’s testing hypothesis and finding product/market fit; there’s prioritizing the roadmap (or more likely these days, deciding not to use a roadmap at all)… the list goes on and on. So naturally there’s quite a bit of writing on this topic. Most product management advice (including, ahem, a certain book) covers this area of fresh or updated products very well. What we see less of is articles and books about how to manage a well-established product.

What do I define as a well-established product? It’s fuzzy, but I see it roughly as a product that has been in the market for more than a couple of years, has a steady and growing revenue stream, as well as a few healthy competitors. The reason I’m interested in well-established products is because, well, Postmark (where I work) is one. We have a product that most of our customers love, and it’s growing in both users and revenue. Of course we have ideas on how to make it better, but we’re in a different stage of our journey. We’re not frantically playing catchup with competitors or trying to complete a bunch of features that aren’t adding value to any customers yet.

This is, I’ll admit, a wonderful position to be in as a product manager. But it doesn’t mean there’s no work to do. I’ll stop short of pulling out the “software is never done” trope (in fact, I’d argue that software can be done). I will say that we’re definitely not done with ours yet. So as a product manager, I learned this year that well-established products face a different set of challenges than newer products. Here’s an incomplete list of my hypotheses about managing such products:

• Prioritization becomes a much finer art (with a little less science).
• Roadmaps become more important.
• Process becomes more necessary.

I’d like to spend a little time discussing each of these issues separately.

Prioritization

When I started at Postmark we went through a full product discovery and prioritization exercise. I wrote a long post about it on our blog: How we built a product vision and roadmap. I also followed that up a few months later with From roadmap to shipping: effective product management for remote teams — a post on how we moved from strategy to execution. Something I didn’t get into in those posts is how my understanding of prioritization evolved as we moved further into the details.

Postmark is a tool for developers. That means that feedback from customers comes in often, and it comes in detailed. Feature requests are usually incredibly specific (and useful), ranging from a field that’s needed in an API, to missing functionality and how that affects their business. Due to the sheer volume of high-quality feedback we get, I learned quickly that I needed an efficient way to categorize and prioritize things as they come in, otherwise everything would just go die on a backlog somewhere.

The biggest shift here was to move to a system where we prioritize themes, not individual problems or features. A theme is loosely defined as a particular customer problem or opportunity we need to solve — similar to the “hypothesis” nomenclature in lean development. Now, when new ideas come in to JIRA (Yes, yes, I know; more on JIRA later) — either internally or from customers — I follow a set of steps to (1) process and (2) prioritize them:

1. First I do a gut check: is this something we’d ever do? Does it point to a customer problem or business opportunity that would be beneficial for all of us to solve? If so, great. If not, the request gets rejected with a note so we can get back to the customer or internal stakeholder.
2. If a theme already exists for a particular idea (e.g., Improvements to the Bounce webhook, or Improvements to the Statistics page), I add it there, and considered it processed. It would be too overwhelming to think through the details of every single idea, but I know that when the time comes to work on a particular theme, it’ll be there, and we’ll go through it then.
3. If a theme doesn’t already exist for that idea, it gets a little trickier. Is this important enough to group together with other things to create a new theme? Do we expand a theme to “make room” for the idea? This is where things get decidedly less certain, and I have to be comfortable with a certain amount of fluidity. I might create a new theme, only to merge it into something else later. That’s ok. As long as it’s somewhere manageable where we won’t forget about it, I’m happy.

During our quarterly planning I don’t make the team go through every single JIRA ticket (to their enormous relief). Instead, we discuss our OKRs (Objectives and Key Results) for the quarter, and then decide which themes to work on that line up with those OKRs. Once our themes are prioritized, I work with the teams to figure out how best to address it — it’s usually a combination of some of the ideas already inside that theme, and a few new ones we come up with.

And this leads me to my next point…

Roadmaps

I’m still quite amazed at how out-of-fashion roadmaps have become. It seems to me that a lot of people got burnt by 2-year corporate plans that weren’t allowed to change, and then decided that the only way to deal with that (admittedly atrocious) situation was to get rid of roadmaps altogether.

I respectfully disagree.

I’ve written about this before, so I’ll just reiterate one bit here:

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.

This is, in my experience, especially true for a well-established product. There is a lot more leeway to mess around and see where things go on a new product. With an established product, it’s way too easy to get off track (Evernote, anyone…?). So what I argue for is a flexible quarterly roadmap of prioritized themes. You don’t write down dates next to a long list of features. You don’t make hard commitments for releases that might never happen.

Instead, you put together a list of themes you’d like to work on, in order of priority, based on how closely they align with your objectives and key results for the quarter. And then you meet every week as a core team to discuss a couple of things:

• Did any new theme arise over the week that is important for us to discuss?
• If so, and if we should work on it soon, what does it replace?
• If not, then let’s get back to work.

This keeps the roadmap flexible, and it keeps the team aligned on what the most important themes are for the product and our customers.

Process

Which brings me to my last point… process. I’ll quote Michael Lopp on this until the day I die:

Engineers don’t hate process. They hate process that can’t defend itself.

Considering the sheer number of detailed input we get on the product as well as the amazing ideas coming from inside the team, there’s no way I could just wing it. Maybe there are some PMs who can hold everything together in some kind of virtual kanban board in their heads, but I just can’t do that.

So yes, we use JIRA, and you know what? It works for us. The Customer Success and Marketing teams submit ideas and hypotheses with links to the customers who request it. If and when those ideas make it into a theme, they continue to add more customers to it as we go. They can always see where something is in the development process, and when it gets released they get to go tell a bunch of customers that the thing they asked for is now live. And that is really cool.

I understand why people hate JIRA, I really do. But I think I’m such a big proponent of it because we were able to come up with a way for it to benefit the whole team, and actually make their lives easier, not harder. We have a process that can defend itself. And I don’t think you can work on a well-established product without something like that.

---

This year has been an enormous learning experience for me. I’ve never worked on a product like Postmark before. It’s a product that is basically universally loved, where feedback comes in from people who are passionate about it and can’t imagine their development lives with out it.

As much as it is a dream to work on a product like this, I feel like I had to learn a whole new set of skills to be effective as a product manager in such an environment. I know I still have a long way to go, but I can tell you one thing — I’m excited to learn more in 2017.

Alex Maughan voices some things I’ve been thinking about as well in a great post on user journey mapping. After one particular project he observed this:

This user flow may seem an obvious solution, but it wasn’t obvious to the company hired to design the app before I got involved, which had up to that point resulted in some very limiting and confusing design flows. I don’t say this to blow my own horn. The point I’m making is had they explored the designs with some rough, high-level journey sketching upfront, they probably would have realised this themselves.

I’ve become increasingly convinced that there is no complicated design problem that can’t be solved with a few hours of collective thinking and some boxes and arrows. Yeah, I get some eye-rolls for my boxes-and-arrows reliance sometimes—especially because the outcome sometimes feels just too simple. But I’m with Alex on this one—these things are only simple in retrospect.

I recently worked on a project where we had to figure out the migration paths of 6 different products, and how they will all work together. We were talking for a long time, but we didn’t really get anywhere until I started drawing it out on the whiteboard. The end result was deceptively simple (some parts blurred out because it’s roadmap stuff):

“That’s it?” we all said of what came to be known as the Tron diagram. Yep, we realized together: that’s it. But it took a few hours of discussion and drawing to get us to the “that’s it” state. So this is me adding my voice to Alex’s in saying: never underestimate the power of sketching flows and user journeys to help us solve difficult problems.

A few years ago I almost went insane with commute-madness (which I’m reasonably sure is a thing). We lived in Bloubergstrand in South Africa, and I worked in the city of Cape Town. This meant that I had to be out of the house and on the road before 6am every morning (and leave work before 4pm), otherwise I would spend upwards of 90 minutes in traffic, as opposed to the more manageable (or so I thought…) 50-60 minutes.

It’s a little too soon for me to talk about the effect that commute had on my mental health, so I’ll just say this: I didn’t handle it well.

So I, along with thousands of my fellow commuters, rejoiced when the city of Cape Town extended the popular MyCiTi bus service out to where I lived. My joy was short-lived though. It turned out that even though they extended the bus line, the City decided not to provide parking nearby. So unless you lived within walking distance of the bus stop (which I didn’t) you were out of luck.

This seemed really silly to me, so I asked about it, and found out that the City didn’t want to provide parking until they could prove that the bus line was successful. It doesn’t take much to see the gigantic failure in logic here. The City didn’t want to provide parking until they could see that enough people used the buses, but not enough people can use the buses if there isn’t parking.

We ended up moving back to the city.

I tell this story because I recently got into a discussion with Vincent Hofmann, based on this tweet of his:

Cycle lanes in South Africa are a great idea but we’ll need orgs to get ready for healthier commuters with supporting infrastructure.

— Vincent Hofmann (@vincenthofmann) March 7, 2016

I brought up the MyCiTi thing, and then mentioned how different the experience is here in Portland, where I live now. I bike to work every day, and the only reason I can do that is that the end-to-end experience is designed well. It’s not just about the city installing bike lanes. Neighborhoods have to agree to stricter traffic rules. Companies need to provide facilities for safe bike parking and showers. It’s a collaboration between public and private sectors across the city. If anyone doesn’t pull their weight, the whole thing falls apart.

Luckily, in Portland, it all hangs together really well. Here are some photos of my end-to-end biking experience in Portland:

There is, of course, a big product management lesson here. We often spend so much time trying to perfect the experience people have with our products online, and we forget about what happens before and after they get there. And that’s often where the experience breaks down and we lose customers. As an example, I mentioned in my newsletter over the weekend how frustrating it can be if you can’t contact a company after making a purchase:

It sounds obvious, but it is still amazing to me how many companies see support as a liability. Any opportunity to interact with customers is a good thing. Yes, it’s expensive, and “case deflection” is a very effective way for companies to cut costs, but at what cost? A case deflected—either through finding the answer on a forum, or a customer simply giving up when they can’t figure out how to contact the company—is a missed opportunity to build loyalty and get input on your products.

And this, ultimately, is why customer journey mapping is such an essential activity for any product. It forces us to think about designing the end-to-end experience, from long before people get to our site, until long after.

Evidence of the danger of only focusing on the product experience itself is all around us—just look at the way our cities design public transport and bike commutes. Notice the differences between the two examples I shared above—one set up for failure, the other for success. And let that be a challenge to all of us to think about how people experience our products even when they’re not using our products.