2 Things the Agile Manifesto Completely Missed that Legacy Enterprises Can Learn from the Product Manifesto
Since the Agile Manifesto’s creation 20 years ago, organizations now regularly spend billions to undergo Agile Transformations. But the despite these efforts, flawed logic underlying the Agile Manifesto continues to lead to a series of destructive preconceptions that affect teams, businesses, and users daily:
- Agile will help you build faster
- More & better working software will make the world a better place
- Pleasing the people who hired you to write the software is all you need to do
The Agile Manifesto’s biggest flaw: the “service provider” mentality
The Agile Manifesto signatories were simply trying to design better software engagements.
But every company is now a software company, and software is the main way of delivering value. Companies that don’t recognize this treat “Agile” teams as “cost centers,” & subject them to factory measures of productivity – how busy people are, number of features released – with little to no improvement in the value delivered to customers.
The newly-released Product Manifesto recognizes that it’s not about shipping more software, but about addressing user needs through two crucial mindset shifts:
Delivering on outcomes is the only measure of success.
The Product Manifesto moves away from the legacy “service provider for hire” mentality, measuring success not by feature acceptance but by effectiveness at solving meaningful customer problems.
Cross-functional teams doing discovery deliver better outcomes.
The Product Manifesto lays out a series of powerful discovery principles, including starting with “why,” effective framing, quantifying through data, working backwards from goals, and regular customer contact that help reduce risk in delivering better user outcomes, and ultimately, business results.
While still a classic document with much to offer, think carefully about which Manifesto will be the cornerstone of your organization’s transformation.
But everyone should understand the fundamental modern Product Management mindsets and why they’re important
“The leader-leader structure is fundamentally different from the leader-follower structure. At its core is the belief that we can all be leaders and, in fact, it’s best when we all are leaders.”
― L. David Marquet, Turn the Ship Around!: A True Story of Turning Followers into Leaders
I recently worked with a product person who had been trying to refine user stories with a development team over several discovery sessions. One developer finally gave up and demanded, “Why don’t you just tell me exactly what you want?”
Obvious vs. Complex Challenges
Telling developers, testers, and designers “exactly what you want” works fine when the work is obvious and straightforward. However, when teams are tasked with delivering more innovative solutions, or achieving more significant and meaningful goals such as increasing NPS or decreasing churn, the challenges become complexin nature. Complex problems are considerably more ambiguous and have no single “best” way to conceive, design, or deliver them.
Implications for Requirements
User stories and Jobs to be Done stories are tools specifically designed to reduce those risks by recasting complex requirements in terms of simple stories or the expression of unfulfilled needs. This allows teams greater freedom in figuring out both what to build and how.
Interestingly, just as important as the solution the team arrives at is the trust, learning, and growth that develop over the numerous conversations that take place when these cross-functional teams embrace the Continuous Product Discovery process in parallel with Continuous Delivery.
Implications for Leadership
Looking more closely, it’s easy to see that this desire to see complex problems as simple and obvious cuts both ways – leaders who are used to “just telling people what they want” tend to pair well with people are used to “just doing what they’re told.” However, a leader-follower dynamic that’s better suited to solving obvious problems won’t be as effective in dealing with the deeper work teams face in delivering complex solutions that drive real business outcomes.
While all leaders intend to drive meaningful impact for their businesses, it may be counterintuitive for them to grasp that they could be getting better results by not telling people and teams exactly what to do, but empowering them and providing strategic intent. In order to trust them, they’ll need those teams to be made up of people who are ready to step up to those challenges.
Pillars of the Modern Product Management Mindset
Over several years studying the work of great modern product leaders and coaching product managers and teams, I’ve seen a core group of mindsets emerge that repeatedly deliver results:
- Proactive, Ownership Mentality
- Client-Centric Focus
- Continuously Learning
- Strategic & Analytical
These are the inputs, the constructive mental qualities that great product managers bring to their work. Each skill builds on the previous one to create critical mass. I believe that the more teams adopt these mindsets more broadly across the entire team, the greater their ability to deliver innovative, quality solutions that deliver meaningful results.
It’s a given that these teams need to be relatively stable, be granted some degree of empowerment and autonomy, and have the psychological safety to create a culture of continuous experimentation and learning.
Reading through this list, everyone can identify some of these mindsets they may need to strengthen, perhaps some in which they may already excel, and others they may have been completely unaware of until just now, and need to start getting ramped up on quickly.
While traditionally an enterprise problem, even smaller, newer organizations get weighted down by the fiefdoms, hierarchy, and heavy process or compliance constraints that appear over time. This results in a series of constant checks and balances at every product decision point, slowing down the team’s forward momentum. It’s easy for people on these teams to eventually slip into a victim mentality, become passive, and just “do what they’re told.”
People who give up in the face of organizational bureaucracy aren’t wrong – the impediments are very real. However, for those who are more passionate about their chosen vision than accepting the status quo, those constraints become just another set of data points, distractions.
Yes, they must work within process and governance constraints. However, they start by breaking out of their victim mentality, take ownership and keep their focus on what’s within their control now. The rare few who end up making a difference find a way to work through their complex challenges within the guardrails their companies provide and remain resourceful about how they and their like-minded peers continue to make progress towards their goals.
Client-Centricity Starts with Talking to Humans
Historically, putting the customer at the center of the team’s focus has taken some form of either “the customer is always right,” or building whatever the customer says they want, neither of which allow teams to make great products.
Modern product management approaches client-centricity in a fundamentally different way, through the lens of empathy. True empathy for clients’ needs can’t be faked, and there’s no shortcut for it.
Many organizations work to understand their clients by engaging external agencies to interview people, do research, and provide a slick report at the end. Another popular enterprise tool is to send out surveys and make decisions based on a few responses.
While these approaches can be helpful, true client-centricity is far simpler: It’s the people actually doing the work interviewing the people who use their product. It’s listening deeply to customers talk through their pain points to uncover hidden opportunities, and using the team’s skills and experience to come up with solutions.
Before teams can collaborate effectively, they need trust, respect, and psychological safety. The next step is to break down silos and hand-offs within the team, encouraging a more open, inclusive, and flexible working approach.
Some examples of this could be testers collaborating more closely with developers earlier on, rather than waiting for code to be handed off. Or designers reaching out to developers for feedback on different design approaches before waiting for a refinement session. As teams begin working across divisions, the team’s level of collaboration increases to the point that they’re able to handle progressively more complex challenges.
True collaboration means not only working together to solve problems, but also encouraging everyone on the team to fully share in presenting their work to others, and participating in the success and credit that comes as a result of that effort.
One of my favorite quotes illustrates the essence of this kind of collaboration:
“Faster alone, further together”
As the team is exposed to truths about their product and their process, they need to continuously adjust course and incorporate improvements on a regular basis. Equally, they need to pull data from all sources (see the next mindset on data) to derive any insights that could feed back into the next set of ideas and improvements.
One of the biggest mindset shifts teams encounter embracing agility is that Discovery isn’t something that’s done once and abandoned once their code gets pushed to users. Continuous Deployment to production represents just the next phase of their learning. Only once the application is in their customer’s hands will they begin to understand if it’s achieving what they thought it would.
There are two critical questions to ask:
- Has the application been properly instrumented with analytics?
- Has the team found the right metrics to track?
Ongoing customer interviewing and close collaboration with internal sales and client support teams is also crucial to gain valuable insights, broaden understanding, and continuously learn and iterate.
Continuously learning teams also focus on constantly expanding and broadening their skill sets and knowledge to work towards becoming more “T-Shaped” in their capabilities to allow the team to deliver a broader range of capabilities and solutions.
Strategic & Analytical
Critical, systems-based thinking is the foundation for creating a mental model, and coming up with the strategies that drive prioritization, decision-making, and deciding what to optimize for.
If the goal is to grow household share, and the strategy is to drive more daily active users (DAU), then paying those users to use products will work, at least in the short term. However, if teams are focused on growing a brand and creating a loyal, committed client base, teams need to work to provide solutions and experiences of much greater value.
Without hypothesis-driven thinking, everyone on the team will jump from one shiny object to another, unable to align on the strategy underlying the priorities and stay focused on the crucial outcomes.
Data Driven vs. Data-Informed
Analytical thinking opens the door to being more data-informed. In rigidly data-driven environments, decisions are purely made based on numbers alone. It’s easy to see how quickly this kind of thinking can lead even well-meaning people and organizations astray.
All teams need to ensure their products are instrumented for analytics, and the teams doing the work need to have regular exposure to that data. Without those insights, teams have no criteria against which to view the impact of their past product decisions, and how to get products iterating in the direction of success. But teams need to bring that data together with their critical thinking and collective wisdom to harness it and unleash it’s real power to calibrate consistent iteration towards meaningful product results.
On the Way to Entrepreneurial, Product-Driven, Empowered Teams
Complex, meaningful product outcomes won’t come from a team of order-taking factory workers with a foreman (the scrum master) and a boss (the Product Owner).
They’ll only come from a passionate group committed to their mission and the overall success of their product. Bringing the five evolved product management mindsets to bear, a team of leaders has the potential to view their day-to-day collaboration as an opportunity to bring more of their whole selves to work every day to co-create with the rest of the team.
How can we…
- Always be resourceful and take ownership of finding a way to achieve our goals?
- Keep the customer front and center of every decision-making process we have?
- Increase shared understanding to consistently collaborate better?
- Loop continuous learning into the team and organizational cadences?
- Be strategic and leverage data to enable better decision-making?
All of these approaches fall under one broader category: Product Management.
Ultimately, it comes down to hiring, building, nurturing, and coaching people into leaders, using these mindsets across the entire team in the service of solving hard and meaningful problems.
And that’s not a team I would want to compete against.
To learn more about these mindsets and the product thought leaders who freely share them, follow the writing, podcast appearances, and teachings of Teresa Torres, Melissa Perri, Hope Gurion, Jeff Patton, Jeff Gothelf, Marty Cagan, Christian Idiodi, John Cutler, Rich Mironov, and Shreyas Doshi.
Wanted to thank my friend Andy McNally for contributing the whimsical and insightful Illustrations included in this post. A Sketch Note journalist and illustrator who regularly covers the Apple Worldwide Developer Conference for Cult of Mac, he’s recently moved to full-time freelance design and illustration. Check out his site and his Threadless shop.
Trusting teams to discover, build, inspect & iterate unleashes more than just better solutions
Either explicitly or implicitly, every organization drives towards four people-focused outcomes:
- Deliver great client-centric experiences that also work for the business
- Attract and retain top talent
- Inspire people to give their best effort
- Create a company-wide culture of continuous learning and innovation
The current pandemic has created an incredible pressure-cooker, stress-testing nearly every organization’s readiness to suddenly leap five years into the digital future. But it will take a fundamental mindset shift in how organizations plan and deliver their work to thrive in the face of these challenges and demonstrate whether they truly put their people first.
Time to Convene the War Room…?
Newly-digital leaders who have tested the waters of Agile and Digital transformation may be tempted to abandon their initial forays into servant leadership in favor of a return to the classic “war-room” playbook, grinding scores of developers through brutal 80-hour-plus work weeks to deliver detailed stakeholder-driven roadmaps.
The Comfort of Action
In the face of the current unprecedented circumstances, forcing teams to churn blindly through feature delivery might provide leaders with the comfort that the frenetic activity teams are engaged in amounts to constructive action.
While outwardly impressive, team morale and product quality are the first victims of this unscalable approach. Crucially, by pinning everything on disjointed initiatives, organizations risk not only failing to deliver client-centric experiences, but completely jeopardizing the other three people-focused outcomes noted above.
At What Cost?
Pushed past the breaking point, organizations risk massive employee burnout and attrition. All those great people, hired and onboarded at such considerable effort and expense will deteriorate, waiting for nothing more than the end of the workday and the weekend before they can leave at the first opportunity. Is this a culture that attracts top talent?
What if What the Team is Building is Something No One Wants?
Those who choose to stay, mindlessly building whatever they’re told to may still succeed in delivering something. After the launch celebrations are over, and someone bothers to look more closely, it frequently becomes evident the features they’ve been so busy building for the past 4-6 months are things that can’t be properly built, no one can find, no one can use, and no one wants.
Organizations need to actively question if dictating and forcing teams to follow these “roadmaps to nowhere” are really worth their employees’ lives and careers.
Fortunately, there’s an approach that can provide a central clue to all four people-focused outcomes, offering not only a viable solution to navigate the current pandemic, but to face the equally dramatic competitive landscape yet to emerge.
Managers Don’t Need New People and They Don’t Have to Work Harder
Counterintuitively, leadership can accomplish far greater results than their planned features could have hoped to have achieved with the people already on their teams. And those people don’t need to work anything more than reasonable, sustainable work weeks. As improbable as this may seem, managers who succeed in making the mindset shift and adapt to this way of working will have opened the door to all four people-focused outcomes.
Empower Product Managers and Their Teams
The prerequisite of empowerment is trust. Instead of dictating lists of features for teams to build, management can get more from the smart, resourceful, and dedicated professionals they’ve hired by providing clear product outcomes to their teams, and empower them to own, end-to-end, how teams deliver on those goals.
Simply put, leadership can get far more from their people if they empower and trust them to get the job done, and provide them a safe, supportive environment in which to function.
The people on those teams are closest to those clients and their needs. They are in the best position to ideate and deliver the most appropriate and innovative solutions.
Start with a Clearly Communicated Strategy
Why are we doing this?
Leadership can start by inspiring teams with their shared purpose. Teams work best aligned to a clear strategy and set of objectives, the “why” underlying their work. Leadership needs to own and master the inspirational narrative of what makes their work so critical for the business, and consistently keep telling that story across all employee touchpoints. In a quote attributed to Bill Campbell, “By the time you’re tired of saying it, they’re just starting to get it.”
Clarify the Product Strategy
In order to formulate a clearer and more compelling strategy, Jeff Gothelf shares how leadership can formulate an effective product strategy by answering three simple questions:
- Where will we play?
- How will we win?
- How will we know you’ve won?
Without a clear strategy, teams won’t have a foundation for the hundreds of prioritization and optimization decisions they need to make every day. Short-term activity by paying for users? Long-term nurturing of brand-loyal clients?
Empowered to deliver, and focused on a unifying strategy, teams are ready to work. Before writing a single line of code, they’ll need to kick off ongoing cycles of Continuous Discovery.
Coach Teams to Address Risks Up Front in Discovery
Weekly touchpoints with customers
By the team building the product,
Where they conduct small research activities,
In pursuit of a desired product outcome
The Real Value of Discovery
Discovery isn’t used once to test something and create absolute assurance that teams are building the “single best thing.” It’s a continuous activity to reduce risk as teams gather empirical evidence in the course of iterating towards better client-centric outcomes. To help with this, leadership should encourage teams to follow the Lean wisdom of reducing batch size, and allow teams to quickly iterate through the “Hypothesis, Build, Measure, Learn” loop.
Empower Teams to Build the Smallest Thing, and Watch It
Leadership that trusts and provides psychological safety for teams as they rapidly discover and build the smallest thing they can quickly learn from have taken the biggest steps in the right direction. The next biggest mindset shift is to understand that once the first iteration is built and delivered, the work has only just begun.
Traditionally, launch parties have been one of the few ways for management to give back to their teams. Showing this kind of gratitude is extremely important given the extraordinary effort and sacrifice teams make on a regular basis. However, management needs to reaffirm that simply having shipped doesn’t mean the team’s work is complete.
…But Spend More Time Monitoring Afterwards
Leadership needs to continue to coach teams to be empirically data-driven, and have them closely monitor and take ownership for the fledgling solutions they’ve launched, continually monitoring, discovering, and iterating in pursuit of the product outcomes within their control.
Not Yet Set Up to Monitor?
Without the accountability of data, management and teams have no empirical basis for success or decision-making criteria. Setting up a product operations team, and getting products properly instrumented with actionable analytics, alerts and dashboarding is crucial to provide both leadership and teams a clear picture of user activity and funnels.
Make Sure They Learn from What They’ve Built
Regardless of the outcome, when teams are coached through continuous discovery with regular client conversations, continuously deliver the smallest pieces they can, and regularly monitor the right analytics, they’re well on their way to feeding that information back into the product and iterating towards the client-centric outcomes that can truly move the needle for the enterprise.
It’s All About the People
Through these approaches, progress toward the four people outcomes is now possible:
- Teams engaged in Continuous Discovery and Iterative Development have a far greater chance of delivering better client-centric experiences that also work for the business
- Top talent is far more likely to want to work at an organization that trusts and empowers their teams
- Empowered teams create the internal accountability where people are far more likely to give their best effort
- Teams that engage in continuous cycles of discovery, inspection, and iteration can’t help but contribute to a company-wide culture of continuous learning and innovation
Leadership that truly empowers their teams has embarked on the journey of enhancing the experience for every person their organization touches.
Thanks to Maarten Dalmijn for reviewing an earlier draft of this article and providing much helpful feedback.
As an extrovert who grew up mostly in the New York City area, I’m highly attuned to sense and seize the tiniest microgap in any conversation. As a reformed command-and-control IT program director, I’ve striven in my roles as scrum master and Agile coach to allow my teams the space to step up, be more self-sufficient, and take ownership for their improvement.
Nowhere does this come more into play than in daily scrum. With my collocated teams, I had been able to step back and do little more than nod or raise an eyebrow to get the next person to speak up. This low-touch style has been less effective in the new all-remote world, leading to some lengthy, awkward silences in the spaces I’ve left for my teams to contribute.
Communication style aside, the daily scrum for many teams tends to represent little more than a status meeting, where team members drone on about what they did the day before.
“Yesterday I… “
“Worked on the latest fire drill…”
“Did lots of paperwork…”
“Had a lot of meetings…”
“Ditto to what Sharon said.”
Little wonder people are disengaged and multitasking during scrum. Rather than listen to each other and being ready to interact, they’re focused on getting in and out of scrum as fast as they can
Yet despite the current challenges we face, there exists the possibility that we can not only survive, but prosper in this environment. I’ve uncovered three simple approaches that have helped revitalize my teams’ daily scrums, and if applied consistently and coached, I believe can bring significant value to your teams, as well.
The Real Value of the Daily Scrum
In my view, the two most critical reasons for the daily scrum are to
- Recommit to the sprint goal
- Recommit to each other
If you’re not accomplishing those two pieces at least to a certain degree every day, I believe you’re indeed not only wasting your time, but that of the rest of the team. And it all starts with recommitment.
Recommitting to the Sprint Goal
Without a clear goal for the sprint, the team will be scrambling, unsure of why they’re there, and what most needs to happen next.
The Sprint Goal is a high-level statement focused on the outcome of what the team’s working to deliver within the timebox (“Lay the foundation for our next-generation client experience focused on more individualized and interactive advice”). This is not the same as the list of everything in the Sprint Backlog (User Stories #142, 144, 278, 342, the output). Maarten Dalmijn has written a great piece here on Sprint Goals and their fundamental value to Agile teams during a sprint.
What Each Team Member Can Share
I believe that by encouraging people to slightly shift the content of their scrum contributions – towards a focus on how they’ve directly contributed towards the sprint goal, share what they might need, and what they can offer the rest of the team:
- How have I (personally, uniquely) contributed to the Sprint Goal?
- Where have I experienced challenges that I could use some help on?
- What insights have I gained that could benefit others?
- How and where can I be of help to anyone else on the team?
Recommitting to Each Other
In the course of recommitting to our shared purpose during this sprint, and having each person contribute how they’re bringing the team closer to the shared goal opens space for other team members to say, “Hey, I had that problem as well, and got it resolved. Let’s chat after scrum and I’ll tell you how I fixed it. Anyone else who needs help is also welcome to join.”
It Doesn’t Always All Have to be About the Work
Daily scrum can also be a great opportunity for the team to briefly reconnect on a human level – something fun you might have done over the weekend, a quick poll, a book worth reading, favorite meme, etc.. Laughing and having fun is another essential element in the recommitment process and helps bring the team closer together.
How Can We Do This Better Virtually?
With everyone now distributed, it’s trickier for people to understand who should contribute next. My aforementioned extroverted and directive nature wants to jump in and control things, where I’d like to provide the space for the introverts to have the time they need to reflect before sharing.
My Agile Coach colleague at Key, Michael D. Blackwell, provided a great suggestion that neatly ties everything together during scrum. Once the first person has shared, they each in turn pick the next person to give their contribution, going through the entire team. I’ve been pleasantly surprised to see how effective this simple technique can be in allowing all voices to be heard, opening up the space for the team to organically manage itself. It’s also cut down on multitasking, as everyone needs to be on their toes, focused on who’s talking and ready to go next if called upon.
In Summary- Recommit!
- Recommit to the Sprint Goal (your team has a sprint goal, don’t they?)
- Recommit to each other by connecting and sharing your contributions toward the sprint goal
- Each person picks the next person to share
Try just these three small things, continue to coach and encourage your teams to make them second nature, and see how your teams start to look forward to daily scrum, nurturing a more vibrant team culture along the way. And once we’re all back standing together again in our team rooms, let’s see if we can continue to engrain these daily habits and how they continue to build collaboration through recommitment, bringing more meaning and value to our work.
Photo Credit – By PierreSelim – Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=17336884
Has Agile Let Us Down?
Are developers really the bottleneck?
In a recent meeting, a senior executive asked a product manager why they couldn’t deliver more of the features requested for an upcoming quarter. The PM replied, “I would, if I could just get another four developers.”
After 20 years in tech, across a wide array of web & mobile front- and back-end technologies, with everything from tiny startups to established, 200-year-old enterprises, I’ve seen this pattern emerge consistently – the underlying assumption that software development is the blocker.
And increasingly over the past 10 years, there’s been this hope that Agile would finally fix that problem.
I believe that software engineering shortages are not a cause but a symptom. We’ll look into where the real problem lies, why asking Agile to fix the problem has created more issues. and where I believe the real solution lies.
Product teams are tasked with delivering from time-sequenced roadmaps, typically made of a random series of stakeholder commitments. Planning is done in advance either every quarter (if teams are lucky), or up to a year or more in advance.
After months of requirements gathering, when the work finally comes to the product team for action, it’s either been elaborated too far in advance in isolation from the team, or cryptically vague. Stakeholders then decry that teams aren’t moving fast enough because they’re unable to get these requests built and delivered at their arbitrarily-dictated roadmap cadence.
Agile to the rescue?
Agile was tapped by the enterprise for one reason – To fix the development team’s efficiency problem. Note one of the original Agile Manifesto signees, Jeff Sutherland, gained notoriety a few years back with his book and associated TEDx talk touting Scrum as the way to get your teams to do “Twice the Work in Half the Time.” (i.e., 4X the work…?)
This is absolute catnip for executives and stakeholders of all stripes tired of waiting for their pet projects to get delivered. So the goal of Agile in the Enterprise has really been focused on getting teams super-efficient to pushing out everything on their roadmaps.
Why are teams being asked to build these things?
With this sole focus on efficiency, and building and delivering “stuff,” that no one has thought to question-
- How good are these ideas? Are they as good as we think they are?
- Will they really make our clients happy and successful?
- How will they contribute to tangible business value?
Set Up to Fail
Given this dynamic, even when product teams are delivering efficiently, all kinds of worthless things that clients will never use can get quite efficiently pushed out the door. Worse, the really important things that clients really do need are getting missed because large enterprises tend to organize around internal silo structures, rather than end-to-end client experience value streams.
Without that client experience-centricity, it’s only natural that key pieces get over-engineered while other critical gaps occur.
And when things do go off the rails, IT continues to put product teams under the efficiency microscope (burndown), while “the business” plows ahead in isolation on an unending stream of disconnected feature request ideas, stocking roadmaps stretching off into the future.
But if the team has just shipped 2-3 features with their latest release, and one of them has not only negated the other two, but beyond that, caused entire critical segments of their user base to get frustrated and churn, what should happen then? And who’s supposed to be tracking that and take corrective action?
Product focus to the rescue
I’ve become increasingly convinced that enterprise embracement of a product focus, versus a legacy project focus, can provide a clue.
As leading product- and design-driven companies like Netflix, Amazon, and AirBnB demonstrate, the goal of modern software development is never on problem-solving over delivery, where the best teams drive a continuous organization-wide learning process, where savvy leaders strive to optimize for effectiveness, build just enough to learn from, and continuously Iterate.
What gets managed in Product Management?
Product managers manage neither the development team, nor their work. Yet without a Product Management focus it’s impossible to provide holistic meaning and clarity around what teams should be building, when, and why.
Not Just Competing Stakeholder Requests, but the Unfolding of a Vision
Instead of efficiently pushing out lists of features in isolation, product-driven teams are focused on the higher-level organizational vision – how does that flow to strategy, and how can teams continuously deliver on that strategy by delivering on measurable, data-driven changes in user behavior.
IT Project vs. Product Focus
Now take a step back and remember how IT tends to view their mission – they’re a
- Cost center
- Managing Projects and Resources to
- Deliver Features
- Incentivized for an
- Binary feature delivery model (ship=1=good)
While the Product Organization seeks to be is teams of
- Vision- and business-strategy-led
- Value producers
- Leading Products and People to
- Deliver Business Outcomes
- Incentivized for an
- Empirically data-driven,
- Problem solving model (customer behavior change+positive business value impact=good)
Asking a New Question first
So Agile hasn’t really let us down, so much as been the wrong question to ask the entire time.
Before putting pressure on Agile to optimize delivery at the team level, companies should focus on an enterprise-wide client experience product focus, which will open the door to a strategic product emphasis on delivering more rewarding user experiences as well as better business results.
The Unifying Power of Product
A truly empowered Product Organization can take a unifying vision and strategy, break that down into data-driven leading indicators of client behavior and discover how best to drive them across the business with self-organizing product teams. With a data-driven focus on the right metrics, the most inspiring vision and insightful business strategy can get transformed into motivated teams building the right things.
When teams are finally empowered to focus on solving the few, highest-priority product-driven client experiences that drive business outcomes, rather than the many disjointed feature requests, there will always be enough development cycles.
“Negative – South Melbourne, Victoria, circa 1934” by Kerr Bros Studio is licensed under CC PDM 1.0