Sachin Rekhi reviews April Dunford’s book Obviously Awesome: How to Nail Product Positioning so Customers Get It, Buy It, Love It in his post Positioning for Product Managers:

While 2000’s Differentiate or Die spoke at length on why positioning is important, it never really went into detail on how to actually go about developing your product’s positioning. The traditional approach is to develop a positioning statement. While useful as an output to your positioning process, it really doesn’t describe the process one could use to come up with such a positioning statement. That’s why I was excited to read April Dunford’s new book entitled Obviously Awesome, which is an in-depth tactical guide on how to go about actually developing your product’s positioning.

The reality when it comes to positioning is that most companies end up with default positioning. This is simply leveraging the positioning that the original folks who came up with the product concept thought about when they conceptualized the product offering. But what’s important is to be deliberate about your product’s positioning because a great product could end up failing due to poor positioning alone.

He also discusses April’s advice to replace a “positioning statement” with a deeper 5-part positioning framework which defines the following for your product. This is a really good summary of the book.

In his post Why Feature FOMO Stalls Product Innovation Brian Crofts discusses the many reasons why product teams tend to add a slew unnecessary features to a product. This issue hit close to home:

Pendo’s recent State of Product Leadership survey found that 77% of product teams are evaluated based on the number of features they ship. This gives product teams an implied incentive to add more, regardless of whether those features are being used and adopted.

I can only trust that this has changed by now, but when I worked at eBay product managers were measured by how many PRDs they wrote. The things didn’t even have to ship. The measure was literally “How many Word templates did you fill out this quarter?”

Instead, Brian proposes a better way:

Technology brands should hold their product teams accountable for metrics that have the greatest impact on success. Instead of the raw number of features shipped or revenue driven, metrics such as feature adoption, customer happiness, and customer engagement are critical. These measures point to which features are working now and help form longer-term rollout strategy.

In 8 essential metrics for measuring product-led growth Katryna Balboni discusses a few important metrics for measuring and monitoring product-led growth (i.e., turning users into advocates so that they can they drive more acquisition and growth). Time to Value is one that seems particularly useful:

Time to value (TTV) is the amount of time it takes new users to realize your product’s value. Your goal should be to reduce time to value as much as possible-the sooner users reach their first aha moment or activation event, the better.

To do this, focus on optimizing your user onboarding experience around the key actions within your product that correlate to activation-like inviting colleagues to your platform, importing customer data, or integrating with other tools in their tech stack.

This was fun. I got to talk to the productboard team about our values and how we approach product strategy at Postmark. Here’s an excerpt from the article For Postmark, Product Excellence means enabling startups and developers to build great things:

For every feature that goes into delivery, and when considering Postmark’s product as a whole, Rian aims for customers to have two primary responses. One is: “Well that was easy.” The second is: “I don’t mind paying for this at all.”

“We want to create enough value so we’re not seen as just another app that our customers have to grudgingly pay for every month. We want to be the kind of software that we ourselves would enjoy using and paying for. I feel like that’s such a great metric: ‘I happily give you my money.’ That is the best response to a product.”

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

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.

I really like Matthew Ström’s concept of Responsive Roadmaps that “visualize the process of turning uncertainty and complexity into outcomes and output.” He presents this as an antidote to all the things that are wrong with traditional roadmaps:

Traditional project roadmaps are right about our knowledge in a moment of time. They are good records of our beliefs about the correct sequence and magnitude of our work. But these roadmaps are wrong about the reality of work, and almost every roadmap I’ve ever used goes out the window as soon as the work starts. No battle plan ever survives contact with the enemy.

Responsive roadmaps are right about the nature of work: it is full of uncertainty and subject to change. They are wrong about what we’ll be doing in the future; the farther out we look, the less accurate a responsive roadmap is. That tradeoff affords us time to focus in the present on delivering at the highest level of quality.

He goes into much practical detail on how to create, maintain, and use responsive roadmaps.

I really like Jeff Gothelf’s approach to the question “Does every project need to be Agile?” in his newsletter issue Digital transformation is not innovation:

No. Every project does not have to be Agile. However, each project you work on should encourage and support agility. This means that every initiative creates the ability, desire and safety to change course in the face of evidence that contradicts our original plan.

He goes deeper on what it means for teams to have the ability, desire, and safety to change when needed.