The role of instinct in product development

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.

Mutemath on creative collaboration and the importance of (sometimes) working alone

I’m a really big Mutemath fan. If you haven’t listened to their latest album, please do yourself a favor and get on that! In the Rolling Stone interview Mutemath’s Paul Meany on Near-Breakup, New LP ‘Play Dead’ they talk about their creative process on the album:

Mutemath assembled the track list in an unconventional way. Instead of arguing endlessly over what songs to pull from their massive pile of 30 demos, the musicians each hand-picked three and assembled the basic framework themselves before bringing the other back into the process.

”We just trusted each of us to go into our corners and materialize a vision for that particular song and bring it back to the band to finish the puzzle together,” Meany says. “And it was exciting to watch everyone in the band firing on all cylinders. The mantra was just ‘indulge,’ and we trusted each other to do that. And we wouldn’t have been able to do that a few albums ago. If you just get into ‘indulge’ mode, that’s usually the recipe for garbage. Every person in the band should always feel that – someone’s gotta to create some parameters at some point. But I think we’ve worked together long enough now and have developed the trust within that creative space to just say ‘go.’ This was the culmination of all that.”

I tend to think that’s a great way to collaborate on design as well. Go away and do your thing with no constraints, come up for air and get feedback and make changes, rinse and repeat.

The value of product specifications: a modest proposal

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.

[Quote] Plan All of the Things!

I find teams generally do a good job of thinking of the features that make up the core customer-facing functionality of their project. It’s the non-customer-facing features that tend to be forgotten.

James Hood on why software project estimates are so often wrong, from Plan All of the Things!

The biggest mistakes product managers make (and how to avoid them)

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.

DIKW Pyramid

  • 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.

How smartphone usage affects teens’ mental health

I should start by stating the obvious: I like technology and phones, and I think it’s essential for kids to be exposed to it so that they can be prepared for the future ahead. That said, despite its click-bait title, Jean Twenge’s Have Smartphones Destroyed a Generation? really got to me. She studied how teens tend to spend their time, and how it affects their mental health, and came to some alarming conclusions:

More comfortable in their bedrooms than in a car or at a party, today’s teens are physically safer than teens have ever been. They’re markedly less likely to get into a car accident and, having less of a taste for alcohol than their predecessors, are less susceptible to drinking’s attendant ills.

Psychologically, however, they are more vulnerable than Millennials were: Rates of teen depression and suicide have skyrocketed since 2011. It’s not an exaggeration to describe iGen as being on the brink of the worst mental-health crisis in decades. Much of this deterioration can be traced to their phones.

I know that sounds a bit like fear-mongering—and maybe it’s not as bad as Jean makes it sound. But it’s still worth reading the article and making up your own mind based on the data presented.

Fidget no more

Listen, I held out as long as I could with this whole fidget spinner thing. Sure yeah “It’s only $3, Dad!” but I just couldn’t get myself to do it. And then my 7-year old used the age-old trick used by 7-year olds for centuries: she went over my head and convinced my wife to buy one for her a couple of weeks ago.

Of course, the joke’s on her, because the fad is basically over. Why so soon? In The Rise of the Fidget Spinner and the Fall of the Well-Managed Fad Charles Duhigg takes a fascinating look at why fads… well, aren’t what they used to be. It all comes down to how they used to be managed carefully by marketing & sales departments, as is still the case with Beanie Babies:

In reality, though, all these middlemen were often crucial to ensuring that the pie was baked at all. As Osborne learned when she started selling Beanie Babies, middlemen like Joyce are often the ones who turn a fad into a sustainable business that creates jobs. You might think a company’s main function is to make stuff. But that’s usually wrong. Making stuff is often the easiest part of what a company does. It’s everything else — marketing and defending intellectual property, coming up with distribution strategies and knowing when to stop manufacturing Peanut the Elephant — that’s the hard part. That’s what middlemen do.

Anyway, consider this your PSA that we appear to have finally seen the last of those ghastly things.

Personas and Jobs-to-be-Done: a match made in heaven

I’m guessing that not everyone is going to agree with NN Group on this one, but I’m on board with their article about Personas vs. Jobs-to-Be-Done:

With the popularity of the JTBD paradigm, there are calls in some corners to abandon personas, suggesting that JTBD has emerged as a more useful technique. This point of view is based on a fundamental misunderstanding of the purpose of personas as primarily demographic representations of users, missing the key behavioral considerations that are essential to good personas and that provide much needed guidance for interaction design and product strategy.

The thing is that, as I have written in Job stories are great, but personas aren’t dead, we shouldn’t confuse marketing personas with design personas, which are specifically created to guide the development of product features. Design personas are based on needs, goals, and dimensions that have a direct impact on their interaction with the product.

Good design personas are complementary to JTBD, not in conflict with it. As NN Group further explains:

Well-executed personas are based largely on rich behavioral characteristics, attitudinal data, and insights about mental models, and they require qualitative research with real users to uncover the why behind users’ behaviors. These rich personas typically will include information related to specific goals that users must achieve when they use the product; these goals are directly comparable to the information found in the jobs-to-be-done definition.

So instead of choosing between Personas and JTBD, I’d like to have both, please. I’ll use Personas to get a better understanding of the goals and needs of our target market, and I’ll use JTBD to help create the products that will meet those goals and needs.

Using mind mapping to clarify your job and bring order to task-switching chaos

In a recent blog post about our 4-day work week experiment at Wildbit, Natalie (our CEO) wrote about some things we’re doing to focus our jobs a bit better. The example she used in that post is the exercise I went through to clarify my role as product manager, so I thought it would be interesting to talk about that process a little bit more.

If you’re in a position where you’re a little unsure about the focus of your role, or what exactly you should be working on day-to-day, you might find the process I describe here useful to help you figure it all out.

What exactly would you say you do here?

Even though no one can quite agree on how to define the role of the product manager (but you should totally read my book about that), I think we’re all in agreement that it requires lots of different kinds of tasks—which results in lots of context switching. This means that focus is a constant struggle for PMs. Yes, this is true for many roles, but it is especially true for PMs since the ability to switch between different tasks is so central to what we do to help keep things moving.

The issue is not just that switching contexts all the time is hard, it’s also that knowing what to switch to next can be such a challenge. PM minds are in a constant state of prioritization and reprioritization.

It’s with this as background that Natalie and I had a very long 1:1 a few months ago as we realized I’d drifted away slightly from what my core focus at Postmark needs to be. As we got our development process nailed down, that part of the business needed less involvement from me so I started to spend more time on things like metrics frameworks and improving our prioritization methods. Because that’s just what PMs do—we look for things to fix, and then we jump in.

I had a huge realization that I was starting to spend time on the wrong things when Natalie said to me,

Rian, stop trying to turn us into a big company.

That is arguably the most important thing she has ever told me. Because that is exactly the path I was inadvertently going down. Process improvements aren’t bad, but at that time it was not what the team needed. So we got to work to find out what our team needs in our context and our culture.

Mapping a chaotic role into submission

Natalie encouraged me to go through an exercise she has gone through before. It involves creating a detailed mind map of all the things you do during a particular week, and then using that to identify and prioritize your focus areas. I jumped into MindNode, and after a couple of weeks of working on it with Natalie, we came up with the following map of what my focus areas should be:

Mind mapping your focus areas

It looks all neat and sensible now, but it’s worth mentioning that the process was messy for a quite a while. My natural propensity for order made me want to start at the left with the big buckets of my role, and then expand to the right into more and more detail. In practice it didn’t work like that at all. I ended up starting with cataloging some of the mid-level tasks I spend my time on (such as Regular customer calls and Prioritization). With those things as a starting point I then branched out—sometimes to the right (Customer calls leads to defining that we should talk about Pain points), and sometimes to the left (Prioritization leads back to a larger Planning bucket).

I also ended up deleting a bunch of stuff on the far right during my discussions with Natalie. Specifically, we started to see where I was doing too much of the things that the marketing team was doing already. Once we had a visual picture it was easy to see where I need to scale back, and which areas need more definition.

Bringing order to day-to-day tasks

Once this was done, as I stared at the map for a while, I wondered if I could somehow use it to make my days a feel a little less arbitrary. So I took it one step further and simplified my role as a progression from Listen to Think to Act:

Mind mapping your focus areas

This model now helps me prioritize my days when it comes down to deciding what to work on. If I’m in Listen mode I’m more likely to spend most of the day on calls and discussions with the team and customers. Other days are primarily focused on Act so I tend to spend a bunch of time in JIRA or Basecamp creating the content we need on projects.

This has helped a lot with the scattered feeling I often got when switching contexts too much. I still switch between tasks, but keeping it in the same “family” helps so much with focus and productivity.

In summary—I think you should do this

Creating this mind map has been an eye-opening experience for me. It not only helped me to clarify what I should work on (and when), it also constantly ensures that Natalie and I are on the same page about what I should be spending my time on. This is especially important as a remote employee where we don’t catch up all the time about what I spend my time on.

Natalie and I look at my focus areas together and discuss any changes we might need to make. But other than that, I feel confident that I’m doing the stuff that’s most important for our team, our customers, and the business. I like that feeling a lot.

Good/Bad Product Manager: the Wildbit perspective

I think most of us know Ben Horowitz’s classic Good/Bad Product Manager post. At Wildbit we have a whole section of similar Good/Bad posts to help define our take on various roles — but until recently, the Product Manager slot was empty. I started working on our take on the Good/Bad Product Manager debate a while ago, and we finally published it last week.

I realized that the most important lesson I learned about product so far at Wildbit is the importance of a happy and effective team, and how much of a Product Manager’s time should be spent on that:

No amount of workshops, sticky notes, or JTBD theory will help you create consistently awesome products that customers love if you don’t work with a team that is fulfilled and motivated.

That might be a slightly controversial idea, and it might not work for every organization. But it certainly works for us. So here it is, our perspective on what it takes to be a good product manager.

More

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. ...
  7. 114