Make customer success part of your product as early as possible

The co-founder and CEO of knowledge sharing tool Guru shares some great advice on product development in Mastering the Art of the Outcome: How Guru Turned Customer Success Into a Company Cornerstone. I especially appreciate his point on the importance of making customer success integral to the company very early on:

“Most young companies will hold off on investing in a customer success manager before they reach a certain annual recurring revenue. You’ll see founders working off of ratios, such as having one CSM for every one to two million in ARR, all while they’re furiously expanding the sales team,” he says. “If you want to stay outcome-oriented, that’s a huge mistake.”

In Nucci’s view, this approach overlooks a simple truth: When the contract is signed, your work is just beginning. “Dedicating a team to customer success lets you optimize for customer outcomes proactively,” he says. “If you neglect customer success, you’re setting yourself up to battle fires as they start, and potentially losing customers along the way. You don’t need me to tell you that’s not a great outcome.”

Like product management, but for home life

In The Slackification of the American Home Taylor Lorenz and Joe Pinsker look at how some households are starting to operate more like businesses:

Incorporating Trello, along with Gmail, into the Parker family’s life has been a godsend, in Tonya’s view. It streamlined family communication, helped keep everyone organized, and added a layer of accountability to tasks. Now, instead of wondering if her children forgot to do something, Parker says she can ask, “How are you doing on your checklist?”

This is a fascinating trend. I can understand the use of Trello, and maybe even Slack, but… JIRA? That seems like a lot:

Julie Berkun Fajgenbaum, a mom of three children ages 8 to 12, uses Google Calendar to manage her children’s time and Jira to keep track of home projects.

How to deal with uncertainty in product development: discovery and assumption mapping

Philipp Krehl has a very thorough, practical article up on Mind the Product called Product Discovery or Product Delivery: How do you Decide? His main thesis is that figuring out when it’s safe to move to the build/delivery phase of a project is all about your level of certainty about the problem you’re solving. He proposes a simple rubric to calculate your comfort level with different product risks:

If you and your team have marked every answer a 3 or below, it confirms that you have a high degree of certainty about your path, and you can start building. You will probably still discover new information but you can just adapt to it — this is why we work with Agile methodologies like scrum or Kanban.

Answers marked with 4 or above indicate areas where you should invest and do product discovery to reduce your uncertainty. At this stage, it’s better to figure out the right thing to do rather than commit to an outcome.

Once you have identified areas which require more understanding you can use an effective technique called Assumption Mapping.

He also provides a good overview of the value and practical aspects of Assumption Mapping, a method I am keen to try out.

How to make accessibility part of the product development process

Shaun Juncal makes a compelling argument in Product Accessibility Shouldn’t Be an Afterthought:

But addressing accessibility early and often—if not making it an ongoing pillar of product quality—is a best practice every product team should embrace. Accessibility enables the maximum number of potential users to engage with products, increasing the total addressable market and avoiding frustrated customers from getting tripped up on accessibility shortcomings. […]

When a product doesn’t fully incorporate accessibility, the company is essentially telling a cohort of potential users that “this product isn’t for you.”

He shares some good advice on how to make accessibility efforts a natural part of the product development process.

No one should ever get fired for doing something to help a user or create a better user experience

Ben Nadel proposes A Good Samaritan Law For Engineers At A Software As A Service (SaaS) Company:

How can we instill in our people the unwavering conviction that they have the freedom to create a better user experience?

One idea that popped into my head was to create a Good Samaritan Law For Engineers: an explicit promise by the company that no engineer will ever be fired for attempting to, in good faith, help a user or create a better user experience. And, I don’t mean as an implicit piece of the Tribal Knowledge; I mean as an explicit, codified part of the culture — an entry in the employee handbook — a poster, up on the wall, that any employee can look at and point to and use in their decision-making algorithm.

This should, of course, be true for everyone in an organization, not just engineers. But I like the point about codifying it — making it a principle that’s published, well-known, and ingrained in the company culture.

Prioritization, product stewardship, and the hardest part about being a product manager

I used to believe that effective prioritization is the hardest part about being a product manager. I don’t think that’s true any more. I now believe the hardest part about being a PM is that there is no way to shorten the time and dedication it takes to become your product and its industry’s most knowledgeable and empathic expert.

But I kind of skipped over some things there. Let’s step back a bit.

Realization 1: it’s not about prioritization

If you put a bunch of product managers in a room it won’t take long for them to start talking about their favorite prioritization methods. And you’ll find me in that conversation as well1. But after working on a fairly small team for over three years, I realize that I’ve been stressing out about prioritization too much.

First, when you’re on a small team there are only so many things you can work on in a (let’s say) 12-week period. In fact, you can do one or two big things, and maybe a couple of smaller ones.

Second, when you can only work on a very limited number of things — and provided your team is engaged in customer and business insights — the most important problems to work on are felt, not calculated. I truly mean that. When we go into planning for a new period of work we keep our business goals close, and the projects we need to work on to deliver on those business goals are in our bones. We talk about it, and debate specifics and implementation details. But when it comes to the problems we need to solve there is very little disagreement.

There’s a caveat: even though the “big rocks” of what we need to work on are well known, the tiny pebbles are not, and that’s where prioritization comes in. Figuring out which bugs to fix, which small annoyances to focus on, which tasks to work on to fill in the time gaps — that takes a lot of work, and that’s where prioritization frameworks can be extremely important and useful. But again, if you’re a small team, you’re not going to have a lot of time for those smaller things, and even then the most important “small tasks” are easy to spot too.

So that’s my first realization: product managers make too big a deal out of the importance of prioritization. Usually the biggest problems to solve are well known, and not in need of constant calculation, mapping, and scoring.

Realization 2: but it is about stewardship

My second realization is this: the hardest thing about being a product manager is that there are no shortcuts to gaining the knowledge and experience we need to be effective stewards of our products. Getting steeped in a product’s functionality, uses, customers, industries, tangential industries, business ebb and flows… those things can’t be rushed. Maybe part of the reason so many product managers feel “crazy-busy” is that they are trying too hard to take shortcuts in this regard.

What does it mean?

I think these two realizations are related. We rely so heavily on prioritization frameworks when we haven’t taken the time to inhabit our products in a way that will give us confidence in the problems we instinctively know that we need to address. There’s obviously an organizational aspect as well — with buy-in, trust, and all the complications around that. But when we become true stewards of our products — steering our teams with care and empathy — not only will we find ourselves in a more relaxed state, we’ll also have more time to solve the problems we focus on and improve our product through the feedback we get from customers.

So I guess if there’s some learnings or advice out of this, it’s simply that the most important thing we can do for our product, our customers, and our business, is to do the work that it requires to become product stewards (that is, “the careful and responsible management of something entrusted to one’s care”) as opposed to just product managers. Instead of relying on short-term crutches like business canvases and prioritization frameworks, let’s take the time it requires to get to know our product, the market, and our business inside and out. It will make every single part of our job easier.


  1. It’s Kano, by the way. Kano is the best one. Don’t @ me. 

“There should be no guilt for refusing to work hysterically”

Katy Cowan’s interview with Frank Chimero is really great from start to finish, and covers so much ground on design and technology and how to think about our work. Frank’s view on the importance of not overworking yourself is refreshing, and we’ll hopefully continue to see more of this kind of thinking:

It’s really easy to think that not working full bore is somehow failing your teammates or that withholding effort is poor work ethic and moral weakness. That thought is worth interrogating, though, and it all seems kind of ridiculous once you get it out in the open. There should be no guilt for refusing to work hysterically.

Build a healthy development cadence by being flexible on scope, fixed on time

Megan Quinn’s post on Development Cadence starts off really strong:

The hallmark of a well-run development engine is a development cadence that is brisk in bringing new products to market without burning out its builders.

And then it only gets better from there. Her point about being “flexible on scope, fixed on time” is spot on:

One way to establish a good development cadence is to commit to a predictable launch schedule and avoid slipping by pushing out features, not time. Some organizations commit to launching every month with the notion of ticks (small feature releases/fixes) and tocks (bigger, marketable moments).

The importance of candid communication when things go wrong with your product

There’s been a bunch of Evernote post-mortems, but I did enjoy the backstory and humor of A Unicorn Lost in the Valley, Evernote Blows Up the ‘Fail Fast’ Gospel. CEO Ian Small also makes a point about honesty and candor that’s really important for product managers to understand. He talks about how customers reacted when they finally came clean about the app’s quality issues:

Customers responded to his candor with a mix of optimism and skepticism, Mr. Small said. “The fact that we were able to tell the truth — that they already knew to be true — was a change of pace, not just for Evernote but for every tech-company relationship they probably have,” he said.

How we communicate when things go wrong lays your company’s soul bare. Hide behind “sorry for the inconvenience” and other fluffy language, and customers will lose trust. Be honest and show true empathy, and you’ll build stronger relationships.

I also really like this quote:

Now Mr. Small faces the challenge of recruiting engineers to fix Evernote’s “unique collection of bugs,” when they could be riding a bullet train to riches at a newer company. Hot start-ups can spend lavishly on engineering talent; they can always raise more if they’re growing quickly. Evernote has a different, more mature goal. It expects to reach positive cash flow this year, with annual revenue of nearly $100 million. “We used to be a movement,” Mr. Small said. “When we were a movement, we weren’t a business.”

Too many companies try to build “movements” instead of sustainable businesses that provide real value to customers.

👉 Also see Ahead of Its Time, Behind the Curve: Why Evernote Failed to Realize Its Potential.

When it comes to prioritization, don’t go it alone

Ulaize Hernandez Troyas makes a good argument for involving full teams in the prioritization of what to work on:

This type of ongoing communication throughout the prioritization process has a definite cost, but the number of benefits from this approach is worth it. We have reduced friction between teammates, which has saved us from long-winded conversations that stemmed from misunderstandings. The sense of ownership and purpose has increased the team’s motivation. On a more personal level, having these open product discussions has challenged my own thinking many times over, which has definitely improved our product direction as a result.

In terms of the specifics of how this works in practice, I tend to prefer a combined approach rather than asking the team to come up with an initial list of priorities themselves. We have a leads team that comes up with a proposal for our priorities for the quarter, based on our business goals and customer insights. We then spend about a week with the entire team discussing our proposal, refining the approach, and making sure everyone is aligned and excited about what we’re working on.

More

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