What it Means to be Product Led
I was talking to good friends last night over beers about how often agile is used incorrectly as a tool to help a company achieve their desired outcomes.
Which led us to discuss two very important questions:
- What do companies want from “becoming agile”?
- How should a company properly apply agile to achieve their goals?
What’s interesting to me is that these aren’t hard questions to answer but they seem almost impossible for most companies to get right. And further, it seems to me there are some very common sense things, not really even agile-specific things, that a company can do to get these things right. I think it’s simply the shift to instilling a product culture and embracing what it means to be “product-led”.
What is being Product Led?
What most companies want in becoming agile is to deliver products to market faster.
At its core, embracing Product Management concepts means baking the strategy into the organizational core, admitting you’ll serve only so many products or services to specific customers, and being crystal clear about the vision for the organization and structuring the teams of teams around the facets of that vision.
So lead with products. Organize around products. And most importantly, structure the teams to have everything they need to deliver on those products.
All of this is organizational design strategy and organizational structure related so far. Where it starts to get a little agile is when an organization then decides to make incremental progress on quarterly goals for those products. Perhaps following an OKR strategy, for example. Now, with incremental goals, how are we going to do the work to achieve those goals? That’s where agile comes in. And any number of approaches can work, but instead of going there, let’s talk about where things go wrong. Most companies embarking on “agile transformations” don’t start with what I’ve said above do they?
How do most companies screw up their transformations?
So, first of all, only big companies that have operated using a different way of working even need to transform. Most startups, by contrast, begin with an experimental and incremental approach to building products and are “born agile”. But there’s something about the complexity of a multi-thousand person company that either loses that focus or are just so old they’ve evolved organically into some form of dysfunction.
Now, many companies do have the right intentions. They might even know all of the right things to do without paying big consultants (haha). As I said, it’s not hard to know what the right thing to do is, so why is it so hard to actually do it then?
Agile was born out of software development (all of the manifesto authors were frustrated with the way their software projects were often late and over budget, etc.) So it’s no surprise, even 20 years later, why we still associate agile with software development and technology delivery. Almost every agile transformation starts in the Technology or IT Department. And what do they do? Form agile technology teams, then get good at Scrum and Kanban. They build on those successes and then what? They try to “scale”!
Here’s my theory. Every agile transformation that tries to scale has to make a decision. How do we form the teams of teams to deliver the strategy of the company? Some companies do a good job here of trying to marry the business folks with the technology folks to be sure we’re building the right customer experiences, embracing customer centricity, and delivering against OKRs that align with a meaningful company vision. But there’s a few things missing there. The organizational design almost always hasn’t actually changed; there are still business teams and technology teams. And guess what gets in the way of a nice product-led cohesive strategy there? Politics. Other messiness often still persists as well: annual financial budgeting, annual HR compensation and review processes, centralized and disconnected marketing campaigns, etc. These are also organizational design challenges. It makes companies lose focus. Some are focused on quarterly goals, some annual, some understand the new company strategy, some are still operating under old models.
So what’s the magic bullet to fix all agile transformations?
Isn’t that the billion dollar question? I have an oversimplified answer, heh. The highest ranking technology agile champion(s) and the highest ranking business agile champion(s) need to get together and work with their CEO and executive team to make the bold decision to stop everything and reorganize the entire company to truly be aligned to the products they’re committed to delivering and then instill a culture that follows through to push the company vision down to the divisions with layers of OKRs and a product-led strategy at the core of the company where every single team and individual is defined by those strategies, goals, and measurable outcomes. See? Simple.
OK, but what’s the incremental or agile way to do that?
Most companies aren’t willing to pause critical business functions for the sake of solving some “simple” organizational design challenges. Forward thinking companies might reorg annually to make progress toward being product-led. To be more agile about it, the company needs to take an experimental approach. Is there one product that is prepared and would benefit from merging business and technology leadership? Form a team of teams that blends all of the skills from the business, technology, and operations to make that product successful. Start small. But have the end in mind. Big problems are often solved the same way we solve small problems.
There will never be a good time to adopt a new process or make big disruptive changes. And yet, the greatest companies in the future will be the ones that take that proactive opportunity to re-align themselves, despite the costs. The ones that keep trying to glue it all together and hope teams work well together will likely just not survive.
If you enjoyed this, please clap and share. It means a lot to know my work on this blog is read and used by agilists out there in the world.
Hi, I’m Brian Link, an Enterprise Agile Coach who loves his job helping people. I call myself and my company the “Practical Agilist” because I pride myself on helping others distill down the practices and frameworks of the agile universe into easy to understand and simple common sense. I offer fractional agile coaching services to help teams improve affordably. See more at FractionalAgileCoach.com
How well is your team “being agile”? Our self-assessment tool focuses on 24 topics of modern ways of working including the Agile Manifesto and Modern Agile basics, XP, Design Thinking, Lean, DevOps, and Systems Thinking. It comes with deep links into the Practical Agilist Guidebook to aid continuous improvement in teams of any kind. Learn more at MakeTeamsAwesome.com
The Practical Agilist Guidebook is a reference guide that gives easy to understand advice as if you had an agile coach showing you why the topic is important, what you can start doing about it, scrum master tips, AI prompts to dig deeper, and tons of third party references describing similar perspectives. Learn more at PracticalAgilistGuidebook.com
Follow me here on Medium, subscribe, or find me on LinkedIn, or Twitter.
