Menu

Posts tagged “product strategy”

Can Every Sales-Driven Company be Transformed to Being Product-Led?

Some solid points in this article from Jason Knight. On product-led vs. sales-led (but could also refer to engineering-led) organizations:

To be honest, my strong opinion is that if you have to worry about who’s “leading” anything, then you’ve got bigger problems to worry about than who’s leading. If your entire company is aligned around what’s important and how to get there, then anyone could “lead” you there. This is supposed to be a collaboration, not a dictatorship. If one team “leads” and others don’t agree with where they’re being led, fix that! I generally find that misalignment is one of the most important problems to solve in any struggling company.

Hard agree with that one. I don’t believe in “healthy tension” between product and engineering. Just like I shy away from the traditional hierarchical view of “bosses tell employees what to do”. Whether it’s Product and Engineering or Manager and Teammate… it’s about partnership and helping each other (and the company) grow. We have to reframe this idea that adversarial relationships somehow create better teams and products.

The Language of Business

Bit of a clickbaity title, but there’s some good advice for product managers in this article about making sure the organization understands that product is a profit center, not a cost center. This is the most important point:

Directly tie product to revenue. One way to do this is revenue attribution. In most companies, revenue and revenue growth is tied to marketing or sales. Making the point that product provided the thing to sell and the features that draw in customers is difficult to make. Product, in this regard, looks passive, and marketing or sales are actively doing something. It is easier to attribute recurring revenue to product because it prevents churn and increases upsells and add-on products.

This can be harder to do with some products—like a platform product with lots of internal customers. But the work is important. As Mike Fisher points out in Language of Business:

The lingua franca of business is finance. Each discipline speaks its native language, be that engineering, marketing, product, etc. but when they get together the common language that everyone should understand is finance.

And what that means for PMs:

The core message I want to convey is that understanding the language of finance is not just about adding another skill to your repertoire, although that is worthwhile; it’s about bridging the gap between technical expertise and business acumen. It’s about translating the complex, technical projects we work on into narratives that resonate with stakeholders across the board, narratives that clearly articulate value, risk, and return. This skill set enables technologists, engineers, and product managers to not only defend their projects and ideas but also to align them more closely with the strategic goals of the business.

Dolly, Beyoncé, and Differentiated Value

Thanks to April Dunford for this fantastic reminder about positioning (and life!):

My favorite positioning quote is from Dolly Parton, who said, “Find out what you are and do it on purpose.” A great positioning exercise is a structured process that allows a team to get real clarity on exactly “what you are” so marketing and sales can “do it on purpose.”

Come to her article for the Dolly Parton quote, stay for the Beyoncé positioning lesson…

Draw it until it works

Here’s a quick thought about ramping up on something new as a product manager.

If I don’t understand how something works in an organization, I do two things. I ask questions, and I draw boxes and arrows based on the answers. People sometimes make fun of me for this, but hear me when I say that nothing gets people aligned like a systems diagram they can disagree with.

B2C, B2B, Platform, Internal… the industry/product type doesn’t matter. Draw the flow of information through your product, get people to disagree, adjust until they agree. That’s the moment when you become a PM that can actually be helpful to the team and the business. You cannot improve the system until you understand it.

The Consensus Fallacy and the Need for Alignment

Josephine Conneely shared some thoughts that might seem controversial in The Alignment Fallacy. The basic premise is that the need for full alignment within a team can sometimes hide some deeper problems within an organization:

The need for complete explicit agreements in organisations can reveal a culture which requires you to be on defense (a cover your a*s culture if you will). Alternatively, it can be driven by a culture which suffers from being too collaborative (it happens). Plans which require committee approval get delayed, often never quite leaving that committee discussion stage. Broad stakeholder alignment is a positive thing that should be strived for but there can be limits. High risk, high reward scenarios rarely get complete agreement up front. Instead, they require someone to step up and commit to pursuing that path.

I agree with this take in general, with some nuances I would add to the language. I see alignment as a communication outcome that should happen in any decision-making culture, whether it’s consensus-driven, command-and-control, collaborative, etc. I would say that the situation Josephine describes in the quote above is an issue with relying too heavily on a consensus decision-making style. Importantly, consensus doesn’t necessarily guarantee alignment. How many times have you walked out of a meeting where everyone agreed on a thing and then the next day you’re surprised because it feels like you agreed to a completely different thing?

So I would maybe tweak the language slightly and say the post is a warning against consensus cultures. Alignment is a separate step from the actual decision being made, and an important one. It aims to make sure everyone understands (1) what decision has been made, and (2) what the consequences/next steps of the decision are. That’s needed no matter what your decision-making culture is.

Building Brex 3.0, March 2024

I wouldn’t want to work in an environment like this because even though delivery is a fun part of building product, I find that for most PMs it’s so much more fulfilling (and you usually get better results!) when they are part of strategy and discovery as well. That said, I’m now long enough into this product journey to recognize that as long as you have a team of people who love execution and are excellent at it, this is a completely valid way to build a company:

We changed this model with Brex 3.0. We killed our planning process, and now have One Roadmap for the entire company. I [Brex CEO] am the ultimate editor of everything that ships. We release 4 times a year, and each release has no more than 3 big themes. This forces me to choose what truly matters, allowing us to make a large, company-affecting investment in the few things that are step-function changes to the customer experience, and drop everything else.

Basecamp works in a similar way, and it works for them. I do appreciate that both companies are honest about how they work, so PMs know what they’re in for and what’s expected of them. The frustration only sets in if PMs think they have some autonomy over their work, and then slowly find out about the “shadow roadmap” they weren’t aware of. Just bring it all into the light, I say.

What is strategy—explained with a useful puzzle metaphor

This is about content marketing but Fio’s post What is strategy—explained with a useful puzzle metaphor is very relevant to product people as well:

At its core, that’s what strategy is: taking a problem, discovering what makes it hard, and finding the right way(s) to solve it. The concept is super obvious when applied to a puzzle: you intuitively know that picking random pieces from the pile and expecting them to slot right into place is not a sensible approach…

…and yet, that’s often how content folks expect marketing programmes to work: we bypass the diagnosis and guiding policy phases, jump straight into picking tactics, and expect that all the pieces will automagically fit together in the end.

Another reminder (which I think we need to hear almost every day) not to jump into implementation too quickly. Take time to understand the problem and the opportunity first.

On empowered teams vs. feature factories at sales-led organizations

I think this is a really insightful comment (LinkedIn) by Ben Erez about the realities of being a PM in a sales-led organization. It’s worth reading his whole argument because it’s definitely a spicy take. But the crux of it is that sales-led organizations cannot function with empowered product teams (I think everyone who reads this blog knows what I mean by that, but just in case, here’s a refresher).

Here’s a key part of Ben’s argument, and the really spicy part:

I think sales-led companies should embrace the feature factory culture fully; stop evaluating PMs by their strategic contribution (a weight off the PMs shoulders given they never get time for strategic work anyway) and start rewarding PMs based on how many features they ship that the sales leaders care about. This will align the PMs in your org to think and work the way the sales team (and CEO) wants them to work. It’ll kill many unhealthy tensions in the org and get people rowing in the same direction.

Would I want to work in that environment? Probably not.

But most b2b SaaS companies are already sales-led. And there are thousands of PMs in those environments who feel the tension I’ve described. So I think most b2b SaaS PMs would celebrate their company embracing their feature factory and just calling it what it is.

Could this be seen as defeatist? Maybe. But I also think that the “just calling it what it is” part of the argument is really key here. It doesn’t serve anyone—not the product, not the company, and certainly not its customers—to pretend you have an empowered product culture when you do not. So remove the pretense, and just be honest about who you are.

If you want to become an empowered organization, that’s great! But that’s a transformation that has to come from the executive level, and it’s not a short or easy process. So go on that journey, yes! But until then, be honest about what the organization is, make expectations clear to PMs, and reward them accordingly.

Organizational health is (still) the key to long-term performance

This is an excellent read from McKinsey. It turns out that, unsurprisingly, organizational health is (still) the key to long-term performance:

McKinsey’s Organizational Health Index (OHI) continues to show, for instance, that, over the long term, healthy organizations deliver three times the total shareholder returns (TSR) of unhealthy organizations, regardless of industry. Other findings point to greater resilience and higher financial performance in healthy organizations, even as the world around them has become that much more complicated.

This bit particularly resonated with me:

According to the OHI research, companies with leaders who take decisive actions—and who commit to those decisions once they are made—are 4.2 times more likely to be healthy, as compared with their peers.

But it’s not enough just to be fast with those decisions; our OHI research shows that decisive leaders who empower their employees (giving those closest to the work the autonomy to make their own decisions) are 85 percent more likely to improve the quality of organizational decisions, as compared with their peers.

I’ve long been a fan of the adage “move decision-making to those closest to the data”. This research shows how important that continues to be for companies to succeed and employees to remain happy and fulfilled.

Quality vs Quantity

Mike Fisher preaches the good stuff in Quality vs Quantity. He talks about the importance of shipping small, incremental releases to customers:

By prioritizing the quantity of opportunities to learn, teams encourage a culture of continuous learning and flexibility. Each iteration becomes a learning opportunity. This method aligns more closely with real-world conditions where customer preferences and market dynamics are constantly evolving. Furthermore, this approach reduces the risks associated with big launches like Windows Vista, where a significant investment is made in a single, large-scale product release. Instead, smaller, more frequent releases allow for adjustments and refinements based on actual user feedback and engagement.