2 Things Legacy Enterprises Can Learn From The Product Manifesto That The Agile Manifesto Completely Missed
Since the Agile Manifesto‘s creation 20 years ago, organizations now regularly spend billions to undergo Agile Transformations.
But 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-for-hire 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 – value delivered to customers is either an accident or an afterthought.
The newly-released Product Manifesto recognizes that it’s not about shipping more software, but about addressing user needs through two crucial mindset shifts:
#1: 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.
#2: 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.
Not Everyone Should Become a Product Manager
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
- Collaborative
- 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.
Taking Ownership
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.
Collaborative
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”
Continuously Learning
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
Hypothesis-Driven
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.
Empowering Teams Delivers the Enterprise’s Most Crucial People Outcomes
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
Leadership can support product managers and the teams they lead to deliver improved customer-centric solutions through Continuous Discovery. Teresa Torres defines Continuous Discovery as
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.
Celebrate Effort…
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.
Three Ideas for Better Remote Daily Scrums
Boost team engagement and throughput with these mindset shifts
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.
The Drudgery of the Typical Daily Scrum
Communication style aside, the daily scrum for many teams tends to represent little more than a dull 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 & iterate the plan for the next 24 hours to achieve it
- 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:
- What’s my plan for the next 24 hours to get the team one step closer to the Sprint Goal?
- 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!
Remember…
- Recommit to the Sprint Goal and your plan to (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
Will There Ever Be Enough Dev Cycles?
Are software developers really the bottleneck to value delivery?
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 executive, offering support, said, “I’d be happy to just get you another four developers…”
After 20+ years in Tech consulting, 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.
Twice the work in half the time…?
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 only 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,” 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 first and foremost, 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.
But prioritizing the Product discipline has to be a conscious choice.
What gets managed in Product Management?
Ironically, 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 Strategy
Instead of efficiently pushing out lists of features in isolation, product-driven teams are focused on the higher-level organizational Mission – how that flows to Vision, which results in strategy, and how can teams continuously deliver on that strategy by delivering on measurable, data-driven changes in user behavior targeted through Outcome-focused Objectives and Key Results (OKRs).
IT Project vs. Product Focus
Now take a step back and remember how IT tends to view their mission – they’re a
- Technology-led
- Cost center
- Managing Projects and “Resources” (people) to
- Deliver Features
- Incentivized for an
- Efficiency-driven
- Binary feature delivery model (ship=1=good)
While the Product Organization seeks to be is teams of
- Mission-, Vision- and Strategy-led
- Value creators
- Leading Products and People to
- Deliver Business Outcomes
- Incentivized for an
- Effectiveness-focused
- 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 starts with a unifying Mission, Vision, and Strategy.
They break that down into a client journey underscored by client-centric success metrics that provide leading indicators of client behavior that equal success for both them and the business. Teams then employ Continuous Discovery to figure how to best Discover and Deliver solutions through autonomous, self-organizing, empowered 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 fewer, highest-priority product-driven client challenges that also deliver real 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
The Radical Mindset Shift Leaders Can Use To Help Their Agile Teams Deliver More Value
Posted on May 21, 2022
It’s not because they’re not working hard enough
The fully-staffed, cross-functional, multi-faceted team. Photo by Haste LeArt V. from Pexels
Many technology leaders I coach express frustration with their Agile teams.
They don’t feel they’re delivering consistently, not pushing features out at the promised cadences. Or the teams are not held responsible for making commitments because they’re “Agile.” So the natural reaction is to move the people (“Resources”) around more, push harder, maybe add a few additional developers.
Unfortunately, all these approaches make things far worse.
The effect of a pure Project Thinking focus
When leaders focus only on Project thinking:
📌 When Will It Happen?
📌 Who Will Do It?
📌 What Else is Like This?
📌 How will we do it?
Directly traceable from the “When” and “Who” questions they’re constantly asking, they tend to believe the “ Individual Resource” is the unit of measure.
Increasing Utilization at all costs
All systems in legacy Enterprises are created and maintained with an obsession on Utilization — keeping all workers busy 100+% of the time.
To do this, a Subject Matter Expert (“SME”) or tech specialist (Database Administrator, or “DBA”) role gets split, with one person fulfilling the role on as many as 5–10 teams simultaneously. In order to keep that person busy, we’ve now exploded the number of external Dependencies. Who gets to decide, across the 5–10 other work streams, which should be prioritized first? Is it up to the individual? What happens when five or more teams, or 50+ people, are blocked from moving forward waiting for the same person to address their tech need?
Across the many legacy Enterprises that have moved to Agile delivery methods, measurement remains on factory-focused Output goals:
📌 Hours worked
📌 Story Points completed
📌 Stakeholder-requested features delivered
We only get more of what we measure for
Because increasing individual utilization or questioning deep siloed specialization is never raised, it therefore seems entirely logical that simply adding more fungible developer “resources” will increase the team’s ability to deliver more of what they’re measuring for — Story Points & Features.
But introducing more people to a team actually destabilizes the Storming-Norming-Performing cycle, massively sabotaging the team’s ability (definitely in the short term, if not longer) to deliver “any” intended results until they’ve re-stabilized.
But the software engineers were never the real constraint in the first place.
So the real underlying bottlenecks don’t get addressed, and there’s no lens through Project Thinking and seeing Individuals as the Unit of Value Delivery that will ever cause leaders to look there, massively increasing risk that anyvalue will get delivered at all.
Project Thinking isn’t all bad
There are times when execution are important, and it’s important to realize it’s not an either/or situation–only to understand how the focus on Project Thinking may be impacting our teams’ in ways leaders don’t see as important.
A potential shift of thinking and focus
Leaders who shift to including Product Thinking in their focus:
🎯 Why is it important?
🎯 What are our goals?
🎯 What else could happen?
🎯 How will we differentiate?
Become open to the possibility of seeing the Team as not only the unit of measurement, but the engine of engagement, creation and achievement, and use a new set of success metrics:
🎯 Throughput and Flow Efficiency — Delivering sooner
🎯 Value delivery towards Outcome-focused goals
🎯 More customers succeeding in ways that work for them and our business
The impacts of Product Thinking and seeing the Team as the unit of Value Delivery
As they grow in size, teams within megacorps and startups tend to implicitly bias more towards Project Thinking and not enough Product Thinking.
Product Thinking is a mindset and a process that, once you see, you cannot unsee it.
Shreyas Doshi
The Product Thinking shift
When leaders shift to the priority (“Why is it important?”) and strategy (“What are our goals?”) lenses of Product Thinking, several important shifts take place. The primary concern moves away from keeping people busy — to making sure teams are set up to deliver the highest-priority work done soonest.
The impact of this shift becomes two-fold — how teams are staffed, and what gets measured.
Measuring Teams instead of The Individual
When Leadership puts different systems in place measuring Teams instead of Individuals, the following three steps emerge:
When we fully-staff teams with “T-Shaped” people…
Moving away from siloed areas of expertise, by encouraging hybrid, “T-Shaped,” “Pi-Shaped,” or “Comb-Shaped”skillsets, people on the team can expand their interest and engagement by learning and becoming proficient in other skills areas.
The software engineer who has Quality Assurance Automated Testing experience, or DBA skills. The UX Designer who can do some front-end coding. By decreasing specialization means…
…Dependencies get reduced…
The can reduce their reliance on narrow specialists outside of the team. They take increasing control of their destiny, and can manage their time across the full range of tasks that need to get accomplished.
…and the right metrics start to move
Once leaders staff their teams full time, and encourages their people grow skillsets across the team, and start to measure their teams for Throughput or Flow Efficiency, they’ll see that a higher percentage of teams will improve in their ability to go from idea and working tested software sooner.
Shifting to an Outcome delivery focus
When fully-staffed versatile teams are tasked with delivering client-centric and business success Outcomes, (typically in the context of a well–implemented OKR engagement), leaders can further eliminate the need to micromanage traditional factory measurements of hours worked, velocity, and number of features delivered.
Measure the Team, and move to an Outcomes-Delivery focus
Once leaders balance their Project Thinking with Product Thinking, they can fully-staff their teams, and measure by a different set of metrics, from those suited to factory work to those suited for responding quickly in an uncertain environment to rapid value delivery, achieving both people and Outcome goals.
OKRs Won’t Work if Your Org Won’t Make this One Mindset Shift
Posted on May 17, 2022
Just keeping people busy won’t help if they’re focused on the wrong things
Organizations from small startups to global enterprises have adopted Objectives and Key Results, convinced that simply using the framework will automatically spark new levels of success and innovation.
Much of Google’s exponential growth and impact over the past 20+ years has been attributed to their extensive OKR use, and Spotify, Twitter, and LinkedIn have also adopted them. But the method alone is not the only reason for their success.
For larger, non-digital enterprises, using OKRs effectively will require one fundamental culture shift in how work is assigned, tracked, and rewarded.
Shift from over-indexing on activity and output to outcomes and impact.
Many organizations focus purely on activity and output metrics — they’re highly visible, easy to track, and binary. “Collect 4 use cases; Deliver chatbot feature; etc.” People at all levels of the organization are offered significant rewards to excel at execution.
From an OKR standpoint, shipping means nothing.
Only outcomes matter– changes in customer behavior after the work is delivered (increased usage, improved sentiment) that drive business impact — increased revenue. Everything should be measurable.
OKRs require new levels of strategic clarity, humility, and team empowerment.
Managers in legacy organizations decide quickly what they want built, believing the selected solutions will drive the intended business results.
By contrast, managing via OKRs requires leaders to state, “Team — given our retention strategy focus, engage and delight clients using your deep knowledge of the technology, the clients, and the data in a way that will deliver us these results.”
OKRs can deliver on their promise, but only if management starts with a clear strategy, and empowers teams to deliver client behavior change outcomes that ladder up to business impact.
The Real Reason Your OKRs Suck And The Only Thing You Need to Set Them Properly
Posted on May 10, 2022
A mindset shift to embrace client-centric measures of success
Objectives and Key Results offer the promise of the most powerful modern goal-setting framework, proven to offer exponential results.
Unfortunately, given most Enterprises’ factory-based mindset focused on efficiency and productivity, they’ve struggled with the new OKR goal-setting framework. In my work coaching teams in 200 year-old enterprises, I’ve seen them repeatedly lay out their existing Gantt-chart project plans as OKRs.
Management then wonders why teams don’t deliver the anticipated results.
Enter Product Thinking
Shreyas Doshi (@shreyas) shared a fundamental keystone to setting better OKRs with his revolutionary Product Thinking concept in this Twitter 🧵:
Shreyas boiled down it down to these five essentials:
- Suspend the Project Thinking mindset
- Prioritize your real goals
- Understand your users’ needs
- Generate options
- Simulate
It suddenly dawned on me that legacy Enterprises are stuck in Project Thinking, and leading with Product Thinking is the key to better OKRS.
Using product thinking to help you set better OKRs
Instead of being inwardly-focused on the Project Thinking values of When, Outputs, and Efficiency, setting better OKRs involves leading with Client-Centricity, Why, Outcomes, and Effectiveness.
Project thinking-based OKR example
Focus:
When, Outputs, Efficiency & Internally-focused
Objective
Get leadership buy-in on the new marketing platform:
Key Results:
- Create 5 use cases in January
- Architecture designed and fully approved
- Test data migration and go live
Note that in the Objective, there’s no mention of the benefit the new marketing platform might provide, just that leadership needs to buy into it (Pure Output).
Of the above three Key Results, two don’t have a number, and the one that does provides no indication of what benefit “5 use cases” might provide.
Product thinking-based OKR example
Focus:
Why, Outcomes, Effectiveness, & Client-focused
Objective
Provide lower to middle-income (LMI) clients with the best financial products for them at the right time in their journey, supporting their improved financial future.
Key Results
- Increase client new account application starts from .03% to 2%
- Decrease declined applications from current 40% to 20%
- 70% of clients state “Yes” to the single-question survey “I feel I’m being provided the best product offers for my individualized needs.”
Thanks to Product Thinking, we now have a strong sense of for Whom and Why.
The above Objective is far more inspirational than just getting a few managers to approve something — We’re now focusing teams on bringing a better financial future to those who need it most, something they can really rally behind. Note the Key Results have a baseline and target improvement that clearly indicates movement towards the achievement of the Objective.
While the Product Thinking mindset will take time to adopt, it’s the key to moving from legacy output focus to deliver meaningful results that matter.
Shout-out to Felipe Castro who offered feedback on a better way to frame Key Results.
Product Managers Need To Balance OKRs and KPIs To Deliver Long-Term Client, Business, And Team Value
Posted on May 9, 2022
When it comes to OKRs and KPIs, it’s not either/or, but AND
Product people are constantly pulled by clients, their teams, and their stakeholders.
Experienced product people know that being quantifiable and data-informed in serving these groups is crucial to continuously tracking progress towards goals and adjusting course when necessary.
Aspirational OKRs matched with KPIs represent the simplest way to align the needs of all three.
OKRs represent the new stretch goals for the team
Objectives and Key Results are set as a team’s quarterly aspirational “moonshot” goals.
OKRs are measures of movement meant to challenge teams to raise their level in solving meaningful problems in quantifiable ways. The goals should seem daunting at the beginning of the quarter, and that’s OK — it’s in the pursuit of those goals that teams will need to dig down and Discover and Deliver their best work.
Think of OKRs as the destination you plug into your GPS.
But pursuit of these lofty goals can come at a price…
KPIs are what you need to regularly monitor and protect
Key Performance Indicators are more static, snapshot measurements.
OKRs are stretch goals. They are shoot for the moon goals. But not everything needs to be pushed. Some things need to be maintained.
Chosen thoughtfully, KPIs can balance the OKRs and zero in on the measurements that can mean the difference between short-term wins and longer-term viability. For instance, the team might have an OKR to increase Average Revenue Per User (ARPU). Easy, just raise prices, right?
Without balancing KPIs like Average Recurring Revenue (ARR) or Retention, the wins of one quarter may come at the expense of future business viability.
Don’t forget people-focused metrics of success
It’s also easy to forget the people on both sides of value delivery.
Client-focused success metrics
Clients are not just vehicles to extract value from, but have their own needs.
As the above examples of ARPU and ARR show, any short-term focus on boosting revenue must always be balanced with churn or sentiment (NPS) KPIs to track whether we’re doing something with unintended consequences.
Team health-focused success metrics
Similarly, the teams doing the work represent needs, wants & aspirations.
Long-term, meaningful client or business goals can’t be achieved at the expense of a regular measurement of Team Health — Happiness, Work/Life balance, Innovation can all be areas to focus on to insure people are learning, growing & continuously improving.
When it comes to OKRs and KPIs, it’s not either/or, but AND –
Always remember the OKR goals you need to push for, and the KPI numbers you need to protect, together with the people behind them.
This post was created with Typeshare
Why Outputs, Outcomes, And Impact Are Important For Enterprise IT Managers New To Agile
Posted on May 9, 2022
Understanding the difference unlocks what “Software Value Delivery” really means
“I’m just going to brute-force this and ship everything by the first quarter.”
An experienced IT manager recently shared how he was getting pressured by leadership to deliver a set of features and technology implementations by a specific date through Agile teams. But no one could tell him what those features were supposed to accomplish. And the Agile teams about to be “brute-forced” knew even less. Not the best start for effective delivery.
Understanding Outputs, Outcomes, and Impact is the key to unlock what stakeholders really want and get Agile teams to step up and deliver work that matters.
Outputs
“Outputs” are the things teams make. Whatever they create, it’s an Output:
- Output: Redesign new login form
- Output: Build new microservice
- Output: Deliver training
- Output: Define use case
(Note that in the above list, “activities” are italicized.)
Everything in project-focused IT delivery stops at Outputs & Activities
IT managers have been traditionally rewarded for getting teams to deliver Output on time, on budget, keeping everyone busy the entire time. But just shipping more stakeholder “stuff” faster and keeping people busy won’t guarantee the business succeeds. Research by Microsoft uncovered that stakeholder-mandated solutions either failed to deliver any value or had a negative impact on their business anywhere from 60% to 90% of the time.
Managers need to shift from this pure focus on Outputs to the next level.
Outcomes
Outcomes are the actions customers take with the Outputs teams create.
In what ways will their behavior change, what will they be doing differently once they’re using what we’ve given them? Everything can be thought of in terms of increasing or decreasing an existing behavior we’re trying to change:
- Output: Redesign new login form >> Outcome: Increase successful customer logins
- Output: Build new microservice >> Outcome: Increase teams’ secure development speed
- Output: Deliver training >> Outcome: Increase manager’s support of Agile teams doing experimentation and iterating based on learnings
- Output: Define use case >> Outcome: Decrease risk by learning which application of our technology will be most helpful to our target persona
Impact
Impact usually boils down to either Revenue ($) or Sentiment (NPS).
As a result of interacting with our team’s work, and having customers taking actions in the ways we hope, will that result in either more money for our company, reduced costs, or our customers speaking positively about our company (alwaysthe most powerful & cost-effective marketing possible)?
- Output: Redesign new login form >> Outcome: Increase successful customer logins >> Impact: Reduce users leaving our service (“churn”)
- Output: Build new microservice >> Outcome: Increase teams’ secure development speed >> Impact: Decrease cost to build secure applications
- Output: Deliver training >> Outcome: Increase manager’s support of Agile teams doing experimentation and iterating based on learnings >> Impact: Decrease cost sunk into stakeholder-mandated “boondoggle” solutions
- Output: Define use case >> Outcome: Decrease risk by learning which application of our technology will be most helpful our target persona >> Impact: Increase revenue sooner
Ultimately, these are all just hypotheses
We can’t know what customers will do with our team’s work ahead of time.
This is why everything in everyone’s backlog is a hypothesis. The goal is to move away from mandating the Outputsthat teams deliver, and get business stakeholders to focus on what Outcomes the work is supposed to drive, and support teams to use the process of Discovery to uncover the best path to drive the right Outcomes and Impact through better Outputs.
What you can do as a manager
Managers can either enforce top-down delivery, or help in two different ways:
- Get stakeholders to refocus on what customer Outcomes they need to drive, with resulting business Impact they want the teams to contribute to
- Get teams to work backwards from Impact through Outcomes and have a hand in negotiating improved Outputsthrough running better Discovery
Remember that product management is the crucial competency to connect Outputs to Outcomes and Impact, and guide the crucial Discovery process — make sure you have experienced product people leading the teams.
Understanding the mental models underlying these terms means seeing how business value really gets delivered, and giving teams the opportunity to get out of “factory” delivery and challenge themselves to deliver better work.
Where to learn more
Watch this short video (~10 minute) by Jeff Patton for a walkthrough of Outcomes & Impact, and why we want to minimize stuff and maximize Impact
Next, watch this video (25 mins) from Josh Seiden on how product management connects Outcomes to Impact.
Finally, Josh Seiden’s excellent “Outcomes Over Outputs” is a great short read you can finish in a day that will help deepen these ideas.
Michael Goitein 