The power of stakeholder promises

In the dynamic world of product management, one thing remains constant: the importance of stakeholders. Whether they're customers, employees, investors, or partners - stakeholders play a key role in the success of your product. How can you ensure that you're meeting their expectations and delivering on your commitments? The concept of "Stakeholder Promises" gives you an answer - so let's explore.

And since we're at it, let's start out with an example of stakeholder promises for this article:

Our promises to Product Owners:
1. You will build better products.
2. You will enhance your professional credibility.
3. You will have more effective stakeholder interactions.

The importance of Stakeholder Promises

Stakeholder Promises play a crucial role in guiding your product development journey. They are more than just commitments; they are the pillars upon which trust, credibility, and alignment with organizational goals are built. Focusing on Stakeholder Promises empowers Product Owners to navigate the complex landscape of stakeholder expectations effectively.

Alignment of Goals and Needs

Stakeholder Promises reflect on your values and your commitment to various stakeholders. By aligning your product with these promises, you keep the work in sync with the broader objectives of the company.

Trust and Credibility

Fulfilling Stakeholder Promises demonstrates your dedication to meeting stakeholders' expectations. This, in turn, builds trust and credibility with your customers, employees, partners, and investors.

Effective Prioritization

Defining Stakeholder Promises helps you prioritize features and enhancements that truly matter to your stakeholders. It's a compass that guides you in making informed decisions about what to build next.

Transparency and Communication

Promises serve as a foundation for transparent communication. You can openly discuss how your product aligns with these promises, fostering a sense of inclusivity and cooperation among stakeholders.

What Are Stakeholder Promises?

Stakeholder Promises are explicit commitments made to various stakeholder groups. These commitments are derived from the vision and encompass a wide range of areas - from customer satisfaction over employee well-being all the way to ethical business practices. Essentially, they represent the organization's pledge to contribute positively to the well-being of all stakeholders.

Take the example of Yamaha, where you see promises made to customers, employees, business partners, communities, and even the environment: These promises form the foundation upon which their products and operations are built.

Defining Stakeholder Promises

Here's a simple process that you can apply for defining meaningful Stakeholder Promises:

Step 1: Identify Product Vision

The foundation of Stakeholder Promises lies in your product's vision. Start by clearly defining your product's vision, which serves as the guiding force for all your commitments.

Step 2: Identify Key Stakeholders

Identify the primary stakeholder groups relevant to your product. These may include customers, employees, investors, partners, and other parties with a vested interest in your product.

Step 3: Relate Vision and Stakeholders

Establish a clear connection between your product's vision and the needs, expectations, and aspirations of your identified stakeholders. This step ensures that your commitments align with your product's overarching goals.

Step 4: Define Everyone's WIIFM

For each stakeholder group, define the "What's In It For Me" (WIIFM). In other words, articulate what value, benefit, or impact your product promises to deliver to each group. Be specific and consider how your product addresses their unique needs and concerns.

Step 5: Make Specific Promises

Make your promises effective and actionable:

• Make your promises specific, so there's no ambiguity about what you aim to achieve.
• Quantify your commitments wherever possible. This allows you to track progress and measure success objectively.

Step 6: Collect Feedback

Before finalizing your Stakeholder Promises, share them with the relevant stakeholder groups and seek their input. Such an initial round of feedback provides valuable insights and ensures that the promises resonate with your stakeholders.

This step-by-step guide will equip you to define Stakeholder Promises that are clear and actionable, and also well-aligned with your stakeholders' expectations and your organization's mission.

Successfully using Stakeholder Promises

Here are six tips to support you in maximizing the impact of your stakeholder promises:

Align your strategy: Your product and any work done on it should directly contribute to fulfilling your stakeholder promises - or at least: not contradict them.

Prioritize: Stakeholder promises help you prioritize what matters: Features that directly address one or more stakeholder needs or expectations have more impact on your product's success.

Communicate: Use Stakeholder Promises as a basis for transparent communication. Regularly update stakeholders on how your product aligns with these promises and any progress made.

Seek feedback: Actively seek feedback from stakeholders, especially those for whom promises have been made. Act on what you learn to improve your product.

Continuously improve: Frequently revisit your stakeholder promises, keep them up to date, and use them as a benchmark for improving both your product and pactice.

Be Responsible: Actively align your actions and outcomes with the standards outlined in Stakeholder Promises.

Conclusion

Never underestimate the power of Stakeholder Promises: They serve as a guiding light, directing your product development efforts towards fulfilling commitments to your customers, employees, partners, and the broader community. By understanding, defining, and leveraging these promises effectively, Product Owners and teams can build products that meet and exceed stakeholder expectations, while simultaneously contributing positively to the well-being of all involved parties. By paying attention to your stakeholder promises, you'll not only create better products - you also build trust, credibility, and sustainable relationships with your stakeholders.

Scope Creep and agility?

"Scope Creep" is every project developer's nightmare. Best case, it only means overtime. Worst case, it means a lot of unpaid overtime, additional meetings, frustrated customers, angry managers and burnout. In any case - not a fun place to be in. But it's a relic from the traditional world of projects - is it?

No. Scope creep can also occur in agile contexts - and it's even more likely than in traditional projects because there are more interactions with stakeholders. But first, let's define "scope creep:"

A developer feeding the Scope Creep in its natural habitat. Image by: AI (picsart.com)

Defining Scope Creep

Let's turn to the Project Management Institute, as they have defined it best:

Scope creep - Adding additional features or functions of a new product, requirements, or work that is not authorized (i.e., beyond the agreed-upon scope)

Project Management Institute (PMI)

Now, what does that mean within an agile context - and how can we deal with it better than in traditional projects?

With every stakeholder interaction, we gain new insights - and so do they. Mutual understanding evolves together with the product. And each time we interact, what we knew yesterday could be invalid today. That's a great opportunity - but also a danger. Especially when we have a tight schedule and/or budget, this evolution can quickly get out of hand and go beyond our limits.

Confining Scope Creep

We have five critical instruments for dealing with scope creep easily and effectively. In combination, they reduce the risks, stress factors, and the negative associations that come with scope creep:

• Visualize anything that's being worked on,
• Agree as a team on what we take into the product, and
• Simplify with the YAGNI principle, i.e., don't build anything that's not needed.
• Limit yourself to a single demand intake channel, creating a controlled, well-managed process that prevents work flowing in from the side.
• Inspect and adapt frequently, validating that we're still in line with what's agreed upon among stakeholders.

Do's and Don'ts

To create the best product with the highest possible value while keeping scope creep at bay:

• DO pursue newly arising opportunities,
• DO capture stakeholder feedback and insights,
• DO address user problems surfacing in our current solution,
• DO consider improvement suggestions that might require rework,
• DON'T let stakeholders haphazardly drop "urgent requests" or "better ideas" onto developer's desks. These options need to be validated and prioritized against other work first,
• DON'T engage in "prioradditization." Anything added must replace or be prioritized against existing work, and there's always an opportunity cost,
• DON'T play favorites. Neither charisma nor positional power mean that an idea is good or valuable,
• DON'T pursue pet projects that may as well be "YAGNI" themselves. Initiatives without significant value don't deserve capacity, and also
• DON'T tolerate "submarines" that avoid agreements, or bypass the demand intake channel. This makes scope creep exactly as bad as we remember from the worst projects.

Closing remarks

Use the five instruments provided. Heed the Do's and Don'ts, but take it easy. "Scope Creep" always means that someone isn't getting what they want, at least not now, so there's going to be a conflict to defuse, and that's where being relaxed, respectful and open-minded come in very handy. With these tips, I hope that you can confine scope creep and avoid the negative consequences associated with it.

10 Things a Product Owner shouldn't waste time on

There's quite a bit of confusion about the Product Owner role - and a lot of Product Owners spend most of their time on low-value, or even detrimental activity, thus having little or no time to succeed in their role. 

Here are ten timekillers that a Product Owner shouldn't waste time on:

10 - Writing User Stories

Too many Product Owners are caught up in "writing user stories," at worst matching all kinds of templates, such as the Connextra "As a ... I want ... so that ..." and the Gherkin "Given ... When ... Then" templates. Unfortunately, the better the PO gets at doing this, the more understanding they amass in their own head before transferring information to the developers. At best, the developers are degraded to a "feature factory," and at worst, they no longer understand what or why because someone else did the thinking for them. A PO is a single point of failure and bottleneck in Scrum, hence they should try to offload as much of what could go wrong as possible.

9 - Defining Implementations

Especially Product Owners with technical aptitude quickly fall into the trap of spending a lot of time on explicitly defining the "How" of solution implementation. Not only do they thus assume a Scrum Developer role, but also they disempower and disenfranchise their team. In a great Scrum team, the Product Owner should be able to rely on their developers for implementation - the PO can reduce themselves to discovering the relevant problem statements.

8 - Writing Acceptance Criteria

Probably the biggest time sink for Product Owners is detailling out all Acceptance Criteria for all Backlog Items to be "ready" for the Sprint. Where Acceptance Criteria are needed, they should be defined collaboratively, using a Pull mechanism (i.e. developers formulating, and then verifying with the Product Owner). 

7 - Ticket Details

Depending on which ticket system you're using, a lot of details are required to make a ticket "valid." That could include relations to other tickets, due dates, target versions - none of these are required for Product Ownership. They're part of the development process, and belong to the Developers. (Side note: Sometimes, Scrum Masters also do these things - they shouldn't have to do it, either.)

The items 10-7 are all indicators that the Product Owner is misunderstood as an Analyst role - which is a dangerous path to tread. By doing this, the PO risks losing sight of the Big Picture, leading the entire Scrum Team off the wrong tack, potentially to obsolescence.

6 - Obtaining precise Estimates

Estimation in and of itself is a huge topic, and some organizations are so obsessed with their precision of estimates that they completely forgot that there's no such thing as a "precise estimate." As I like to say, "If we knew, they weren't called Estimates, but Knows." - Estimates should take as close to no time at all, and if a Product Owner finds themselves spending significant amounts of time on getting better estimates, something is seriously out of tune. Try probabilistic forecasting.

5 - Planning for the team

Team Planning serves three purposes: Getting a better mutual understanding, increasing clarity, and obtaining commitment on the team's Sprint Goal. Many Product Owners who used to work in project management functions before fall into the trap of building plans for the team to execute. This defeats all purposes of the Sprint Planning Event. The Product Owner's plan is the Backlog, which, combined with whatever sizing information they have, becomes the Product Roadmap. Content-level planning is a Developer responsibility.

4 - Accepting User Stories

A key dysfunction in many teams is that the Product Owner "accepts" User Stories, and is the one person who will mark them as "Done." Worst case scenario, this happens during Sprint Review. Long story short: When the team says, it's "Done," it should be done - otherwise, you have trust issues to discuss. And you might have had the wrong conversation about benefit and content during Planning. Acceptance is something either part of the technical process, i.e. development, or something that relates to the user - that is, developers should negotiate with users. The Product Owner is not a User Proxy.

3 - Tracking Progress

Yet another "Project Manger gone Product Owner" Antipattern is tracking the team's progress. A core premise of Scrum is that developers commit to realistic goals that they want to achieve during a Sprint. The Product Owner should be able to rely that at any time, the most important items are being worked on, and the team is doing their best to deliver value as soon as possible. Anything else would be a trust issue that the Scrum Master should address. At a higher level, we have very detailed progress tracking in Sprint Reviews, where we see goal completion once per Sprint. If teams can reliably do that, this should suffice - otherwise, we have bad goals, and that is the thing the PO should fix.

2 - Generating Reports

Reporting is a traditional management exercise, but most reports are waste. There are three kind of key reports:

• In-Sprint Progress Reports, as mentioned above, they are pretty worthless in a good team
• Product Roadmap Reports - which should be a simple arrangement of known and completed mid-term goals, presented in the Sprint Review for discussion and adjustment.
• Product Value Reports - which can be created by telemetry and should be an (ideally automated) feature of the Product itself.

Question both the utility of reports and time invested into reporting. Reports that provide valuable information with little to no effort are good. Others should be put under scrutiny.

1 - Bridge Communication

The final, biggest and yet most common antipattern, of the Product Owner is what I call "Bridge Communication" - taking information from A and bringing it to B. Product Owners should build decentralized networks, connecting developers and stakeholders, avoiding "Telephone Games" that come with information loss and delay. 

When the Product Owner has their benefit hypothesis straight, developers can take care of the rest. Developers can talk with stakeholders and obtain user information by themselves. A Product Owner shouldn't even be involved into all the details, because if they wanted to, they'll constantly find their calendar crammed, and they become a blocker to the team's flow of value - the opposite of what they should be doing!

The Alternative

(About half of the points in this article describe the SAFe definition of a PO, but that's an entirely different topic in and of itself)

After having clarified what a PO should not do, let's talk really brief about what is a better investment of time:

A Product Owner's key responsibility is to maximize the value of the product at any given point in time. That is, at any time, the Product should have the best Return on Invest - for the amount of work done so far, the Product should be as valuable as possible. That requires the Product Owner to have a keen understanding on what and where the value is. For this, the PO must spend ample time on market research, stakeholder communication and expectation management.

From this, they obtain user stories - which are indeed just stories told by users about problems they'd like to have addressed by the Product. The Product Owner turns stories into benefit hypotheses - that is, the benefit they'd like to obtain, either for the company or the userbase. They then cluster benefit hypotheses into coherent themes: Sprint and Product Goals. These goals then need to be communicated, aligned and verified with stakeholders. By doing this Product Owner successfully, they'll maximize the chances that their Product succeeds - and the impact of their work. 

The Product Owner can free time by minimize the time spent on implementation. Successful Product Owners let their development team take care of all development-related work (including Analysis, Design and Testing) and trust the team's Definition of Done. That is, their only contact with Work in Process needs to be renegotiating priorities when something goes out of whack, a value hypothesis is falsified or new information invalidated the team's plan.

TOP Structure - the Product Domain

Many companies misunderstand Product Ownership - or wose: Product Management - to be nothing more than managing the backlog of incoming demand. While that work surely needs to be done, it's the last thing that defines a successful Product Owner - "there's nothing quite as useless as doing efficiently that which shouldn't be done at all," which is what often happens when teams implement requests that are neither valuable, useful nor good for their product.

To build successful products, we need to continuously ask and answer the following questions:

The Product Domain is the third core pillar in the TOP Structure

Direction

1. What's the vision of our product, how close are we, and should we keep it? How does our product make our users' lives better? Where are we in the Product Lifecycle, and what does that mean for our product strategy? Do we have what it takes to take the next step?

Position

2. What does our product stand for, and what not? Will adding certain features strengthen or dilute our product? Are we clear on who's our target audience, who's not - and why? Do we want to expand, strengthen or shift our user base?

Discovery

3. What's the problem we'd like to solve? How big is this problem? Who has it? Is it worth solving? Which solution alternatives exist, is our product really the best way of solving it?

A weak Product Pillar leads to a weak product, which limits opportunities to make the product valuable and profitable - which quickly leads to a massive waste of time and money in product development, whereas a strong Product Pillar maximizes the impact of product development efforts.

Check your own team - on a scale from 1 to 10, how easily and clearly can you answer the questions above?

The Product Owner Role

What concerns me in regards to the Product Owner role: it's so horribly diluted by many organizations that sometimes, practitioners ask me "What's the meaning of my work, and what should I do in order to my job well?"

There's so much garbage out there on the Internet regarding the Product Owner Role that it's very difficult for someone without significant experience to discern what's a proper definition that would help both companies define proper job descriptions, and provide guidance to PO practitioners how to improve. So - let me give you my perspective.

Great Product Ownership

I would classify great Product Ownership into four key domains:

While one of the core responsibilities of the Product Owner is the Product Backlog, it should be nothing more than the expression of the Product Owner's intent. And this intent should be defined by acting on these four domains.

Product Leadership

The Product Owner should be providing vision and clarity to the team, the product's stakeholders, customers and users alike.

Product Vision

Who is better than the Product Owner at understanding what the product is, which problem it solves, why it's needed and where it's going? Great Product Owners build this vision, own it and inspire others to follow them in their pursuit of making it happen.

This vision then needs to be made specific by elaborating long-term, mid-term and short-term objectives - a guiding visionary goal, an actionable product goal and the immediate sprint goal.

Clarity of Purpose

While the Vision is often a bit lofty, developers need substantial clarity on "what happens now, what happens next?" - and customers will want to know "what's in it - for me?" The Product Owner must be crystal clear on where the product currently is, and where it's going next. They must be able to clearly articulate what the next steps are - and what the next steps are not. They need to be able to state at any given point in time what the highest priority is, and why that is so.

The Product Backlog is then the place where the PO maintains and communicates the order of upcoming objectives and content.

Communication

The Product Owner must communicate their product with both internal and external stakeholders. Life is never easy, so they must rally supporters, build rapport with sponsors, and resolve the inevitable conflicts amongst the various groups of interest.

Networking

The product can only be as successful as the support it receives. As such, the Product Owner must build a broad network of supporters, and continuously maintain and grow their influence in their organization - and for the product's market. Keeping a close eye on stakeholder satisfaction and interest, continuously re-kindling the fire of attention drawn to the product is essential in sustaining and fostering the product.

Diplomacy

As soon as multiple people are involved, there tend to be conflicts of interest. Even if there is only one single stakeholder, that stakeholder has choices to make, and may need to resolve between conflicting priorities themselves.

In peace times, the Product Owner builds common ground with stakeholders, so that they are more likely to speak positively of the product.

In times of crisis, the Product Owner understands the sources of conflict, ebbs the waves, reconciles differences, brings people together to work out positive solutions, and mends wounds.

Insight

The Product Owner is the go-to source for both the team and the product's stakeholders when they want to know something about the product's purpose or intent. The Product Owner has both factual knowledge and inspiring stories to share.

Product Knowledge

Caution - the Product Owner isn't a personified Product Instruction Manual, and they don't need to be. Much rather, they should be the people to be able to explain why the product currently is the way it is, and why it's going to be the way it's going to be. They must be able to fully understand the product's capabilities and purpose - and they must be able to convey why these are good choices. 

From a more negative take, the Product Owner must understand the weaknesses of the current product and have ideas how to leverage or compensate these.

And for all of this, the Product Owner should have the domain expertise, market information and hard data to back up their statements.

Storytelling

"Facts tell, stories sell." - the Product Owner's role is to sell the product, both to the team, and to the customers. They should be able to tell a relatable, realistic story of what users want to and/or are doing with the product, what their current pains are, and what their future benefits will be.

"Speaking to pain and pleasure" is the game - touch hearts and minds alike. The Product Owner should be NEAR their users, and bring developers NEAR as well.

Business Acument

The Product Owner's primary responsibility is to maximize the value of the product, by prioritizing the highest value first, and by making economically sensible choices both in terms of obtaining funding and spending.

Value Decisions

There are three key value decisions a Product Owner faces every day:

1. What is our value proposal - and what isn't?
2. What value will we deliver now, and what later?
3. What is not part of our value proposal, and will therefore not be delivered at all?

The question oftentimes isn't whether the customer needs something, but whether they need it so urgently that other things have to be deferred or be ditched.

When anyone, customer or developer alike, asks the Product Owner what is on the agenda today, this week, or this month - the Product Owner must be able to answer in a way that the underlying value statements are clear to all.

Economics

With infinite money and infinite time, you could build everything - but since we don't have that luxury, the Product Owner must make investment decisions - what is a positive business case, what is a negative business case, what can we afford to do - and what can we afford to not do?

The Product Owner should be able to understand the economical impact of any choices they make: More people can do more work, but burn the budget faster. Every feature has an opportunity cost - all other features that get deferred because of it. Fines could be cheaper than implementations, so not everything "mandatory" must be done. These are just a few.

There is often no straightforward answer to "What should we spend our money on this month?" - and considering all of the trade-offs from every potential economic angle before bringing product related decisions to the team or towards stakeholders is quite a complex endeavour.

Economic decisions need to then be transported transparently towards the relevant organizational stakeholders - to team members, who may not understand where priorities come from, to customers who may not understand why they don't get their request served - to managers, who may not understand why yesterday's plan is already invalid.

Given all of these Product Owner responsibilities above, it should be quite clear that the Product Owner must focus and has little time to take care of things that are ...

---

Not the Product Owner's concern

Three domains are often seen as expectations on the Product Owner, which are actually a distraction from their responsibilities, and putting them onto the PO's shoulders actually steals the time they need in order to do the things that make them a good Product Owner:

Project Management

The Product Owner is not responsible for creating a project plan, tracking its progress or reporting status.

Let's briefly describe how this is supposed to happen:

Planning is a collaborative whole-team exercise, and while the Product Owner participates and provides context, a goal and a sorted backlog as input, they are merely contributing as the team creates their plan.

Developers are autonomous in their work, and the Product Owner should rely on being requested for feedback whenever there's visible progress or any impediments hinder the planned outcomes. If the team can't bear the responsibility of their autonomy properly, that would be a problem for the Scrum Master to tackle. The PO should entirely keep out of the work.

Since Sprint Reviews are the perfect opportunity to inspect and adapt both outcomes and progress, no status reporting should be required. A "gemba mindset" would indicate that if stakeholders are concerned about progress, they need to attend the Reviews, and should not rely on hearsay, that is, report documents. 

Team Organization

The Product Owner is not reponsible for how the team works, when they have meetings or who does what.

When Scrum is desired as a way of working, the team should have a Scrum Master. The worst thing a Product Owner can do with their time is bother with introducing, maintaining or optimizing Scrum - they should be able to rely on having proper Scrum in place.

Team events, such as Plannings or Reviews, help the team do their work, and as such, should be organized by the developers themselves, because only they know when and how they need these. The Scrum Master can support, and the Product Owner should attend - but the PO shouldn't be bothered with setting these up, and most definitely shouldn't run the entire show.

If anyone assigns tasks on a Scrum team, it's the team members self-organizing to do this. Having the Product Owner (or Scrum Master) do this job is an antipattern that will hurt the team's performance. The Product Owner should not even need to know who does what, or when.

Development Work

The Product Owner develops the product's position, not a technical solution. They have a team of experts to do this, and these experts (should) know better than the PO how to do this. That means the PO should be able to keep entirely out of design, implementation and testing.

Product Owners actively designing solutions often fall into the "premature optimization" trap, resulting in poor solutions. The best approach is to have the Product Owner collaborate with developers as needed to get sufficient clarity on how developers would proceed, but to focus fully on the "What" and keep entirely out of the "How."

When Product Owners have time for implementation, the product is most likely going to fail: while they're paying attention to the development, they aren't focusing on what's happening to the product and its customers out in the market.

Product Owners have a team of professionals around them who are supposed to deliver a high quality "Done" Increment. If their team has no quality assurance, the solution is to bring testers in, not to delegate testing to the Product Owner.

Where to put the Business Analysts?

A common question that needs to be answered during agile transitions is, "Where do we put the Business Analysts?"

In a traditional project organization, it's quite common that they receive orders from Product / Project Management, create solution designs and hand these over to development teams, this is a poor approach for agile organizations.

Avoid: BA working for PM

We often see that the BA is a go-between for users and Agile Teams, or even for Product Management and Agile Team, both of which are done in the name of efficiency at the expense of quality.

There are numerous highly dysfunctional antipatterns associated with this approach, i.e. things that cause more problems than they solve, including, without limitation:

Antipattern

Problem

Works as Requested

When users ask for something suboptimal, that's what they'll get, because developers are unaware of the user's real need, and the Product Owner also lacks the necessary information to acknowledge alternate solution proposals.

Works as Designed

When Business Analysts make invalid assumptions about the technical solution, developers will strugge to implement based on their design, since developers are not in a position to challenge the underlying assumptions.

Dysfunctional PO

When a PO gets prioritized, "must-do", fully analyzed designs that need to be implemented, their role becomes dysfunctional. All they can do is "push tickets" and fill in templates of work. The PO's main function is invalidated. 
Product Owners struggle to find purpose and meaning in their work, and in such a setup, it's no loss to eliminate them entirely.

Telephone Game

The amount of information lost when users talk to analysts who talk to product owners who talk to developers is staggering. The amount of communication overhead and productivity loss caused by this setup potentially outweighs the benefits of doing business analysis outside the team.

Bottleneck

Separating the BA out as a special function typically makes them a bottleneck. When push comes to shove, incomplete designs are handed to development in a hurry, which often causes more trouble later than the amount of work the BA wasn't able to complete.

Try: BA is part of the Agile Team

An alternative, significantly more agile, approach is to make the BA part of the agile team they're doing analysis for. 
In this setup, the BA is a dedicated member of the Agile Team they're working with - figuring out both the customer needs in the solution, and the developer needs in the design. Their accountability is being a member of the Development Team, contributing towards the Team Goals. 

In this setup, their job isn't "Done" when a design document is written, but when the user's need is successfully met.

From this position, the Business Analyst supports the refinement and elaboration of business value, interacting with users, not as a go-between, but as a facilitator for developers and users.

Business Analysts also support the decisions of the Product Owner, ensuring that backlog items are "Ready" both quantitatively and qualitatively when there is development capacity to pull these items.

This approach to Business Analysis in an agile setup makes BA expertise equally, and potentially even more, important to the success of development as in a traditional setup, without creating any of the above-mentioned antipatterns.

The HR issue

The main challenge that has to be addressed when talking about the new role of the BA is an HR issue:
From a practical perspective, the BA gets "degraded" from being pretty high in the hierarchy of the organization all the way "down to" team member. This often causes resistance, making it look like the way of least resistance is to opt for the prior choice, which creates irreconcilable conflict within the development organization.

As such, there are multiple items to clarify before we can make the BA as valuable as possible in an agile setting:

Focus area

Problem

HR

Address potential HR impediments that make it within a BA's own best interests to not be part of an agile team, but rather outside. Such impediments include salary, career progession and other incentives set by the organization.

Line Organization

In organizations where BA itself is a separate silo, work with the BA's manager to ascertain them that making the BA's part of the Agile Team does not diminish their importance or influence. The main thing that needs to change is that BA's now receive their work from the team.

BA Individuals

Work with the BA's themselves to ascertain them that being part of an Agile Team is, in fact, not a degradation and to discover and resolve the personal issues they have with the new, different ways of working.

ROCE Clusters - categorizing benefits

There seems to be a huge misunderstanding in the Agile Community about what is actually a "benefit". We quickly get into a false dichotomy where people argue that only ledger impact or only innovation should be considered relevant. Let's break with that. There are many types of benefits:

Different ROCE clusters

Before we begin: In no form or fashion would I claim that this is a comprehensive list of clusters, nor that there are no other ways to generate benefits within a cluster than those described: This article is an attempt to defuse the myopic perspective that there is only one way to look at benefits. 

Usually, an initiative aims at a number of ROCE clusters simultaneously. As a Product Manager, you must understand the clusters you're affecting, both directly and indirectly. In such a case, you need to define the target order: what's your primary focus, what consequential effects do you expect?

For each cluster in question, you need some metrics to measure whether you're making progress on your initiative. Financial metrics tend to be the easiest, with capability building metrics being the hardest to figure out.

ROCE Clusters

Every initiative you're pursuing should belong to at least one ROCE cluster. For example, "Reduce server outages for our Online Game from 8 hours a week to 10 minutes a month, to avoid losses caused by offering voucher compensations worth $150,000 a month."

ROCE clustering is very useful in that it can be aggregated quickly to a Portfolio level and gives you a pretty good overview of where you are spending your money: how much do you invest into patching holes, how expensive is your new strategy, and: are you innovating enough? 

If your portfolio contains only a few clusters, you may have a massive strategic problem.

This article describes seven different clusters and some metrics you may pursue within these clusters. You may find different or additional metrics, or you may find some metrics applicable to a different cluster, and you may find that a cluster not listed here is missing for your own organization. 

If you wish to adopt ROCE clustering in your organization, you may need to identify those clusters relevant to your own organization.

Ledger Benefits

Although the most desirable benefits from an accounting perspective, these tend to be the most elusive in practice, as they are often more consequential to other benefits than direct.

The two most common ledger benefits we are looking for are:

• Profits
• Savings

Loss Avoidance

To discriminate this from "savings", let's first define "loss": Loss is an evitable part of your business that only exists because something is messed up.

Common sources of losses are:

• Fines
• Write-Downs
• Cancellations
• Compensations

Capability Building

The problem with Capabilities is that you can't really translate them into money: they translate into future benefits. This makes capability building very risky, because you don't know if it pays off until it does. And that may be years into the future.

Here are some kinds of capabilities you may invest into:

• Strategic Enablement
• Support Infrastructure
• Network Effects

Innovation

Why should we innovate? The modern business-oriented approach is to look at a problem you observe, then solve it. New solutions to known problems are the most common form of innovation, and most companies innovate mostly in a form of local optimization, i.e. solving their own problems. New products often appear on the market when they solve someone else's problem. But there are also other forms of innovation - those which only serve as a foundation for building solutions to problems. This gives us the most common forms of innovation:

• Solving Process Problems
• Solving People Problems
• Solving Market Problems
• Base Innovation

Demand Shaping

It may sound odd, but sometimes, we invest money not to build some product, but to shape demand for an existing product. Demand shaping allows us to optimize the value generation of our products and services - which includes reducing overproduction and overcharging on the one hand, and stress and overburden on the other. It comes in three forms:

• Increasing Demand
• Stabilizing Demand
• Reducing Demand

I would like to go specifically into point 3 - reducing demand. That's an especially good idea on something called "failure demand", i.e. when a service unit (e.g. Complaints, Repairs) faces high demand due to something else not working. It's also an important preventive measure when over-demand would lead to negative business outcomes, such as loss of trust.

Risk Management

Risk Management could include anything that reduces impact and/or probability of anything that affects either us or our customers. Probably the most famous risk management product is insurance, which does nothing other than moving financial risks from our clients onto ourselves. It doesn't reduce probability, only impact.

The most common types of risk we're dealing with are:

• Business Risk
• Operational Risk
• Market Risk

Compliance

The last cluster this article covers is compliance with rules and regulations - in this cluster, we can't win, we can only minimize losses. So, how much should we spend on compliance? As little as possible, and whenever we do, we should try to combine it with at least one other cluster.

Compliance isn't as much about solving problems, as it is about meeting minimum requirements from:

• Laws & Legal
• Market Regulations
• Standards
• Safety & Security

Summary

ROCE Clusters aren't benefits, they help you categorize your benefits in a way that it becomes obvious where your portfolio budget is going and where you're looking for improvement.

You will still need an appropriate benefit hypothesis and actionable metrics to turn this into a relevant business practice. But that's another topic for another article.

Entrepreneurial Value for in-house development

"We can't measure the monetary value of a Feature". A common complaint, and oftentimes mere ignorance. It's economically disastrous for an organization that spends money on software development!

Here are a few simple, effective ways of making the value of development transparent even when developing complex in-house systems:

Core goals

Before we start, we need to understand that there are fundamentally two different reasons for developing software. While occasionally, these goals can be combined, they are usually distinct, and one of them takes priority.

Revenue increase

Some components allow the company to generate more revenue - acquire new customers, sell additional goods, etc. For those components, measuring feature value is very straightforward: The value is the difference in revenue that can be attributed to the implementation of a feature.

In these cases, the value of a feature can be found on the "Assets" section of the balance sheet - the difference between old and new assets.

Expense reduction

For established processes, most of the work is aimed at increasing efficiency through performance optimization - saving time or resources (e,g., packaging / fuel etc.) to reduce expenses.

In these cases, the value of a feature can be found on the "Liabilities" section of the balance sheet - the difference between old and new liability.

Equity generation?

Argubably, there may be features that turn out to neither generate revenue nor cut down on expenses.

Many people argue that "you got what you got", and proceed to treat such features as assets - claiming that they are becoming shareholder equity that doesn't show up as cash flow.
I, myself, would argue that this is not the case.

From a technical perspective, such features need to be candidates for removal - in software, every feature has code, and every line of code increases the product's complexity, and complexity correlates to the amount of work required to deliver future value -- hence, such features, though seemingly innocent, are technical liabilities!

Determine feature value

After the above is established, we will not discriminate anymore whether a feature's value is determined by an increase in revenue or reduced expenses. Instead of providing specific techniques or methods, this section focuses on thinking patterns that help in determining the value of feature.
These patterns can be selected or combined based on circumstance.

Value Stream thinking

Understand the operational value stream you are contributing to, and the place you hold in that value stream. Your contribution to that value stream is the leverage you have for development.
For example, when your value stream produces a revenue of $10000 a day, and after the implementation of the feature, it's still $10000 a day ... how much did the feature add? Maybe it reduced operating expenses. If, however, they are still the same, the feature did zilch.

Theory of Constraints is a great method of figuring out whether it's even theoretically possible for your feature to add value: if you're not working on the value stream's current or next constraint, chances are slim that you will add value to the organization!

Make of Buy thinking

There's an economics proverb, "If it's known, and you can earn money with it, someone is already doing it." In many cases, there's already a vendor solution that does the same thing you would be developing, and that vendor has a price tag attached to their solution.

While you still can't know if that's going to be the actual value of your feature, the NPV is capped at whatever this vendor is asking. So, for example, if you could buy a cloud solution that solves your problem at $199 a month, we ignore discount rates and cash flow, calculating NPV for a 5-year period, we'd end up with the feature being worth no more than $12k. So unless you can deliver it cheaper, you may not want to build it.

Service thinking

If you remember the beginning of the Internet age, AOL was a service born when companies realized that they had capacities available that others would pay for. Internet giants like Google and Amazon have since successfully replicated the model of selling a solution to their own problem to others as well. You already paid for it - so every cent you make with a sale is net profit! What is stopping you from capitalizing on the idea? If you're doing it right, there's even a chance you can make more money off selling the feature to others than the value it has within your own organization! More than one software company was borne out of scratching one's own itch.

Even if you're producing something "in-house", always ask the question, "Who else has this problem, and how much are they willing to pay to get it solved?" - if the answer boils down to, "Nobody" or "Nothing", then chances are that you're solving the wrong problem.

Key concepts every Product Owner must understand

Let's take a look at some key concepts every Product Owner should understand:

Manage options

As Product Owner, you receive ideas for things that your product could do. Each of them is an option of something that could be done.

There's usually a flood of ideas, some are better, others worse. You need to sort them through, typically by ordering them in a backlog.

You choose the ideas: Good ideas, bad ideas - big ideas, small ideas. Your call.
As far as possible, avoid promises to anyone - they reduce your freedom of choice.

Each of those ideas requires you to make a certain investment in order to turn it into a Product.
That investment is, first and foremost, money. You need to secure this investment, lest your idea dies before it is realized. That's funding.

Spend to Gain

As Product Owner, you have a development team doing the work of making ideas happen. It's not important for you how they do this. That's what they are experts for. What matters for you: what they work on, and in which order.

Your team has a finite capacity - how much work they can do per time. If you feed more ideas to the team than their capacity, they won't get all of them done. So choose wisely how you want to use this capacity.

Development work is fuelled by money - salary, infrastructure, you name it. The rate at which your team spends money is your burn rate. There's a one-way correlation between burn rate and money - a slight reduction in burn rate often significantly reduces capacity, while an increase in burn rate often has no predictable influence on capacity.

With a stable team, your burn rate is constant. Once you know your capacity and burn rate, you can figure out an approximate investment required for an idea. Your estimates will usually be wrong, and  a better crystal ball will only reduce your capacity.

Outcome Focus

The Return on Invest is how much money you made off realizing the idea. Oftentimes, it's elusive (you can't really know at all), and usually it's entire guesswork before you're done. So keep the investment low until you actually see this Return on Invest and turned an assumption into hard cash.

Look for small product increments that allow you to generate a constant flow of value.
Don't get blinded by big numbers: It's better to get $100 every month, starting tomorrow - than to get $5000 once, two years from now. There are many reasons for that - the biggest one being that you can't know if you'll get that money until you did.

Entrepreneurship

You must compare your Return on Invest (ROI) with your Investment. Let's assume it's your own business. You'd understand immediately that if the ROI is lower than your investment, and if your cash flow is worse than your burn rate - it's just a matter of time until you have to foreclose.

And that's exactly what a Product Owner needs to do:

1. to ensure that the product generates a positive Return on Invest, by eliminating bad ideas and prioritizing good ones.
2. to ensure that there's a positive cash flow by feeding a constant stream of ideas that can be realized with a controlled investment before making a "pivot or persevere" (build something else or more of the same) decision 
3. to prioritize ideas against one another, by figuring out which ones promise the best Return on Invest

Your job

First and foremost, you have to understand money to be a Product Owner.

The development work is the experts' job. Even on prioritizing and formulating ideas, they could be the experts. 

As long as the ideas the development team realizes result in an overall positive cash flow, the team can continue and grow - the business is healthy. And that's your job. Everything else, you can delegate.

A fictional scenario

To employed Product Owners, I like to give this thought experiment:

Imagine that you were on a bazaar.

1. You can buy the product for the investment required.
2. You get the product delivered after the development time has elapsed.
3. You can sell the product for the ROI it generates in your organization. 
4. The difference is your income.

Would you build the same product?

The problem of Proxy Users

User Stories - what's a user story, what's even a user? And: Why is that important?

The definition of a "user"

User - a person who uses or operates something.
Sources: Oxford, Google

A "person" can be both an individual or a legal entity.
The specific mention of the term "person" is quite important. We will get back to that later.

There are other definitions out there, also - that have a different emphasis:

User - a person or thing that uses.
Sources: Dictionary.com, Collins Dictionary

This definition opens a different way of thinking - that "things" (physical and/or virtual objects) can be users s well.

Types of "users"

There are various types of users.

To explain them, let's take a look at this scenario:

Scenario:
A person has bank account without any deposit money.
The problem? Checks bounce on this empty account.

Here are some core types of potential users and their problems in this scenario:

Category	Description	Example
End user (Customer)	Someone whose problem is being addressed.	Bank client: Bouncing checks means there is unpaid debt.
Service Provider	Anyone who provides a service using the product.	Bank: May get calls from both their customer and the people their customer gave checks to, asking what's wrong.
Intermediary	Representative of the Service Provider towards the person whose problem is being addressed.	Bank clerk: The person at the counter, answering on behalf of the bank what's happening.
Proxy	Representative of the person whose problem is being addresed.	Bank account: A virtual entity that acts as a proxy on behalf of the customer both towards the bank and the customer's transaction partners.
Delegate	Acting on behalf of the person whose problem is addressed.	Accountant: Responsible for balancing the customer's finances.
Administrator	Responsible that the product or service can be used correctly.	Bank IT: Checks need to be rejected rather than processed.

Why is the discrimination between those "users" important?

Know your Users!

Users define success

For example, if you develop in-house business support software, your user is often a single company, which means you'll have an entirely different way of measuring success than if your user is a Customer on the free market (of whom there could potentially be a couple billion). And the value of your product may depend on two categories of users: the Service Provider, whose balance sheet ultimately determines whether you are building the right product - and the Intermediaries, whose use of the product determines whether you are building the product right.

Users want their problem solved

Especially in large corporations, it's easy to lose sight of what the product actually is - and who the users actually are. By solving the wrong user's problems, you run the risk of local optimization - potentially damaging the interests of your real users in the process!

For example, look at this rather typical "User Story":

As a Security Specialist, I want people to choose difficult passwords and short password renewal cycles, so that accounts stay secure.

Then, think of yourself: How would you like it if the engineering team of your favorite app would spend a month to create password rules so complex that you need a PhD in Cryptography just to be able to determine what's a valid password - and then being forced to choose a new, different password every time you log in!

Solving the right problem

Intermediaries, proxies and administrators pose requests on systems, and while their requests are undoubtedly important, they all don't help you to solve the right problem!

Compare, for example, the following two user stories:

As a bank clerk, I want to be able to see the customer's balance with a single click.

As a bank, I want to know why I'm losing customers!

And now, let's add another user story:

As a bank account, I want to let my customer know when I have no money!

Do you see the difference between those three stories?

Users who have no financial stake

The first story may have sprung up from a conversation with a real intermediary user, and it's fairly easy to know whether you are solving this problem. However, it's almost entirely disconnected from the real user's (the customer's or the bank's) problem.
Unless it just by happenchance occurs that seeing customer balance also addresses the second problem, there's a good chance that spending time with the concerns of intermediaries derails the team from relevant business objectives.

Users that don't have a voice

The second story is an existence-threatening problem. Yet the "bank" as the legal entity that gives employment to the engineering team, has no face or voice. Its true voice may be hidden behind layers of management and bureaucracy. It may be too far away from the engineers to give it relevance and too abstract to be worth touching.

Proxies have no real needs

The third story is all too common in large enterprises: Components, proxies - even API's become "users" - assuming that if we service them, we are solving a relevant problem!

There are no proxy problems

Here's an uncomfortable truth: the proxy has no problem.
It's never the proxies' problem - it's ultimately, a customer or provider problem.

Only when real users (end users and/or providers) interact in a way that requires interacting on a path that crosses the proxy, is there a real problem. And there are two ways of solving this problem: either helping the proxy to do their job better - or to eliminate the proxy's part of the process altogether.

Hidden assumptions

There are always hidden assumptions in proxy stories:

1. The voice of the proxy echoes the voice of the unheard real user
2. The proxy is on the critical path of transactions 
3. The proxy is the constraint to the performance of the system
4. A dependency on the proxy is inevitable
5. Solving the proxy's problem is the best solution to the real probem

By accepting the "story of the proxy", which most agile teams do with little pushback or thought, we run a massive danger of sub-optimizing a solution, and limit the solution space. While this can be valid in many cases to provide focus, this begs the question: When, if not during refinement or planning, does the team spend time to think of which solution is the best to solve the most pressing problem?

Working the Constraint

The reason why I harp so strongly on the point of "proxies" and "intermediaries" versus "real users" - is that while they are on the road to creating a higher-performing system, it's nowhere automatic that improving upon their bidding improves the performance of the system.

Theory of Constraints teaches us that:

1. Optimization outside the Constraint is - at best - ineffective.
2. Time spent optimizing outside the Constraint is Waste.
3. To work on the Constraint, you need to know how to optimize it.
4. When the Constraint is operating at its capacity - elevate it!

Here's what happens when you listen to the voices of Intermediaries or Proxies as if they were the real users:

1. You start to forget who the Real User is.
2. You remain oblivious of how the changes you are making affect overall performance.
3. You don't know if you're working the Constraint or somewhere else.
4. You may institute a new Constraint on the Critical Path, worsening the system.
5. You will miss solutions that elevate the constraint, especially if the constraint is of higher order.

Summary

It's not forbidden to have "proxies". It's just dangerous. 

To avoid the most common pitfalls, start asking:

• Do we understand the real customer behind the problem we are solving?
• Is the solution on the critical path to success?
• Are we working the Constraint?

If you can't answer these questions with a clear and resounding "Yes", you're definitely in dangerous territory - and if you can answer any them with a clear "No", you may want to reconsider implementing this story to begin with!

The problem isn't as much who your user is - it's that "fake users" make you lose sight of what value is and how to create it!

The value of idle time

The Product Backlog is a mandatory part of Scrum. Together with the Sprint Backlog, they define both the planned and upcoming work of the team.

There's a common assumption that it's considered good to have a decently sized product backlog, and as many items in the Sprint Backlog as the team has capacity to deliver. Let's examine this assumption by looking at a specific event.

The "no backlog" event

It was Tuesday evening. I had just a busy day behind me.
I was chilling, browsing the Web, when I received a message on LinkedIn. The following conversation ensued:

Mind Lukasz' last statement: "The most impressive customer service ever".
Why was this possible?

Had Lukasz contacted me half an hour earlier, this dialogue would never have happened. Why? Because I would have been busy, doing some other work. Lukasz would have had to wait. His request would have become part of my backlog.

Service Classes

There's a lot of work I am pushing ahead of me on a day-to-day basis.
But I classify my work into three categories:

1. Client related work - I try to cap the amount of client related work, to maintain a sustainable pace.
   It's a pretty stuffed backlog where things fall off the corners every day.
2. Spontaneous stuff - I do this stuff as fast as I see it, because I feel like doing it.
   The hidden constraint is that "as I see it" depends on me not being engaged in the other two types, because these take 100% of my attention.
3. Learning and Improvement - That's what I do most of the time when not doing Project work.
   I consider web content creation an intrinsic part of my own learning journey.

These categories would be called "service classes" in Kanban.
I am quite strict in separating these three classes, and prioritize class 1 work over everything else.

Without knowing, Lukasz hit my service class 2 - and during a time when I was indeed idle.
Since class 1 has no managed backlog, I got around to Lukasz' request right as it popped up, and hence, the epic dialogue ensued.

Service Classes in Scrum

If you think of the average Enterprise Scrum team, class 1 is planned during Sprint Planning, and class 2 activities are undesirable: all the work must be transparent in the Sprint Backlog, and the SBL should not be modified without consent of the team, especially not if this might impact the Sprint Goal.

Many Scrum teams spend 100% of their workload on class 1, going at an unsustainable pace, because the constantly descoped class 3 work warrants future-proofing the work.
Even if they plan for a certain amount of class 3 work, that is usually the first thing thrown overboard when there's pressure to deliver.

The importance of Spontaneity

Few Scrum teams take care of Class 2 work, and Scrum theory would dictate that it should be placed in the Product Backlog. This just so happens to be the reason why Scrum often feels like drudgery and developers are getting uncomfortable with practices like Pair Programming.

"Spontaneous stuff" is a way to relax the mind, it helps sustain motivation and being totally uncommitted on outcomes allows creativity to flourish.

Load versus Idle Time

As mentioned, class 1 is bulk work. As workload increases, the percent amount of class 1 activity quickly approaches 100%. Taking care of class 3 activity means that increasing load quickly diminishes idle time activity to go to Zero.

Since I already mentioned that idle time activity creates magic moments, both for team members and customers, high load with zero idle time destroys the "magic" of a team.

Wait Time Idleness

One source of Idle Time is Process Wait Time.
In a Lean culture, wait is seen as detrimental waste. This is both true and false. It is true when the organization doesn't create value during wait, while incurring costs. It is false when this wait is used to generate "magic moments".

Buffer Time Idleness

Both Scrum and Lean-Kanban approaches encourage eliminating idle time, as would the common "agile Scaling" frameworks. Team members are constantly encouraged to pull the next item. or help others get work in progress done faster.
This efficiency-minded paradigm only makes sense if the team controls the end-to-end performance of the process, otherwise they might just accumulate additional waste. Theory of Constraints comes to mind.

On the other hand, buffer removal in combination with a full backlog disenchants the team - there will be no more "magic moments": Everything is just plan, do, check, act.

Idle Time and Throughput

The flawed assumption that I want to address is that buffer elimination, cross-functionality and responsibility sharing would improve throughput. Maybe these will increase output, but this output will be subject to the full lead time of any other activity.

Backlogs vs. Idle Time

Genuine idle time means that the input backlog currently has a size of Zero and a parallel WIP of Zero as well. There is no queue: neither work-in-progress nor work-to-do.
An idle system doesn't require queue management. When idling, throughput for the next request is exactly equal to work time - the maximum throughput speed we could hope to achieve. This kind of throughput speed can look absolutely mind-boggling in comparison to normal activity cycle times.

The impact on organizational design

A perfect organization takes advantage of idle time points that maximize throughput speed - not efficient utilization avoiding idle time.

Summary

The conversation with Lukasz is an example of the benefits of having idle time in your work.
This kind of idle time allows for "magic moments" from a customer perspective.

Just imagine an organization where "magic moments" are the norm, and not the exception.
This requires you to actively shape demand: when demand is roughly equal to capacity, we can eliminate backlogs.
Demand queues destroy the magic.

Eliminate the queues. Make magic happen.

Let's talk about Demand

While "Agile Development" focuses exclusively on supply mechanics, an understanding of demand mechanics is essential to managing sustainable product development - agile or non-agile, hence I want to lay a foundation of the effect demand has on a development organization.


Synopsis
A basic understanding of the economic dynamics of Supply and Demand is essential to succeed with product development. As development capacity is a limited resource, free market dynamics do not apply to product development. Without understanding and managing demand, agile product development sets itself up for failure, yet few (if any) agilists understand "demand". This article provides a basic explanation of the impact demand has on your development organization - and how you can use this knowledge to increase your odds of succeeding.

Demand in economics

There are huge misunderstandings in the agile community as to what is "demand" - down to the point where people claim that demand management isn't anything other than working the Product Backlog. Since we have ITIL, a lot of IT people seem to confuse "Demand Management" with "Requirements Management" - and conflate "demand" with "requirement", or, using agile lingo, "user stories".
Let's get back to basics for a bit.

The most fundamental concept of Keynesian economics is Supply and Demand. In a free, unrestricted market, this is the gist of Supply and Demand:

Where supply and demand meet, there's an equilibrium

"Demand" is simply how much of a given good or service people request - and "Supply" is how much of that will be available. There is also "aggregate supply" and "aggregate demand" for the whole range of good or services within an economy.

This model leads to some very intuitive statements:

• As price decreases, demand increases. People demand more at a low price.
• As price increases, supply increases. People are more willing to offer things at a high price.
• At some point, there's a market equilibrium: supply meets demand.

To make this article simpler, from now on, I will infer "good" to mean "any kind of service provided by IT development", "quantity" to mean to "the amount of this good [created or requested]" and "price" as "cost of that good". I will ignore the definition of "price" as in whether that cost is opportunity cost, total cost of ownership or whatever - that too, might be a topic in and of itself. For now, just think of the most comprehensive definition of "price" you can imagine.

While macroeconomic concepts can not be applied to a division of an organization without further examination of the existing conditions, this would go significantly beyond a short blog article. To keep matters simple: The development organization (typically IT) offers certain services ("supplier") to the rest of the business and to customers ("consumers"). From there, we get into the nitty-gritty that may be worth another article.

In this context, "demand" is simply everything that consumers want, which the supplier could provide. There is no constraint that "demand" needs to be known or voiced. It can only be itemized once it's known and articulated. Therefore, demand starts long before a specific item appears in a Product Backlog.

Scarcity and Supply Limits

When a resource (in this case: time) in the production of a good is limited, this generates "Scarcity": the quantity of the good is capped due to the supply limt of the resource.

Beyond the supply limit, price is irrelevant. The demand will not be met.

On the right side of the supply limit, price and demand are irrelevant: There is no way to meet the demand - it's economically impossible. Just imagine that you wanted two suns on the sky - there is only one, so it's simply irrelevant how much you would pay to have a second - there won't be another.

We see the same thing happening when a development team (or: the development organization) has a fairly fixed size. You can slice it however you want, a day still has only 24 hours and 10 people are still only 10 people, so there is some kind of limit in place.

Let us simplify our model once again and ignore the possibility of hiring additional people, because we would still need to observe two effects here described quite appropriately in "The Mythical Man-Month" and "The Phoenix Project", that there's no guarantee that additional headcount will increase the supply limit. Even if we could increase headcount and developers were fungible, there would be still diminishing returns and scarcity of available developers, another topic that we can wonderfully descope for another article.

Increasing demand

As our business grows more successful over time. the demand for goods from the development organization increases. Whereas in the initial phase of our business, developers were experimenting a lot and had a fair amount of time to figure out the best solution, increasing demand brings development closer to its supply limit.

While a low demand can be met at a low cost, there is no way to meet the high demand beyond the supply limit that many development organizations experience.

As we get closer to this supply limit. businesses get the impression that their development becomes slower, less flexible and unproportionally costly. Close to the supply limit, the marginal price increases dramatically with ever diminishing returns on invest.

As demand increases, cost increases significantly faster than quantity

The average unit price of getting a new feature also goes up - not because development cost went up, but because of increasing competition over a limited good. Notice that this is demand competition, not supply competition. Demand competition means that people will use their influence and available means to get what they want, so the people with less influence or money will not be supplied.
Or, to translate the impact of demand competition into the world of product development: At some point, the development organization will no longer be able to serve everyone.

If now we translate this into the world of software again: as businesses become more successful, their demand for IT continuously increases. When a specific request arrives in the development organization, it's either on a point in the demand curve where supply can meet demand - or it isn't. If it is not, then it will not be in the future, because demand is moving up ...

A very simple rule of thumb in a limited supply system is: Unless demand decreases at some point, if you can't get it now, you never will.

... unless...
... demand decreases!

Demand Inflation

Which it won't, because everyone intuitively figures out this rule of thumb. As a consequence, we see a followup phenomenon: When stakeholders start to realize that their requests aren't being met, they try to get the development organization to commit to delivering as many goods as eary as possible, because later, it will be even harder to get this commitment!

This is the point where we enter the vicious circle of starting as many initiatives as possible, irrespective of whether there is enough capacity to complete these initiatives. The capacity problem is delegated to the product organization once there's commitment to deliver upon a certain request.

This vicious circle can't be broken on the supply side

The mechanics we see at work here are exactly the same mechanics that you saw during the World Banking Crisis: As soon as a bank declares that they can't pay back everyone's deposits, everyone will try to be the first to secure as much of their deposit as possible.
The announcement that "we can't serve everyone" is enough to start a spiral so powerful that it can destroy corporations and topple governments - what makes you think that your Product Owner will fare better?

Demand Management

A missing piece in the typical agile approach is that typical IT people understand little to nothing about supply and demand - and even less about demand managment.

Demand management isn't the exercise of itemizing and keeping an inventory "user stories" or other backlog items, and determining which items get implemented next (and which won't get implemented at all).

At the very minute a stakeholder receives the idea that maybe the development organization can't do it all, you start a "bank run", inviting all stakeholders to flood you with as many requests as possible, worsening your problem rather than fixing it!

Demand Shaping

A terrible misunderstanding propagated by many agile coaches and trainers is the idea that it's enough to manage the supply side of product development and have a mechanism to determine the priority and content of the product backlog, then being vocal about saying, "No" to requests for goods that have no chance of being implemented.
Simply managing the product backlog is too late in the process and a local optimization.

Let me give you an example of what "demand shaping" means:

The Diner Metaphor

You go into a Mexican diner to have lunch. The diner has already shaped your demand long before you looked at the menu.  You would be irrational to request breakfast for lunch, and you would be even more irrational to request a sushi platter there.
The restaurant probably won't have to tell anyone that both of these requests won't be served, because nobody expects to get served these dishes to begin with. Nobody would feel offended when the waiter tells a person with a sushi craving that there's an excellent sushi bar down the road.

If the diner is high class, they will not serve you a "product backlog", or a list of 150 different dishes that you can choose from. Their menu will contain maybe four to ten items, all of which the restaurant manager knows to be fast and profitable to produce at a high quality.

The next step of demand shaping happens when you approach the door and see this giant sign "Lunch Menu $6.99"  with some really tasty looking food imagery. At this point, most customers will already have lost their interest in the menu and place their order. The placement, the imagery and the price tag are enough to reduce the demand for other items by a good 80% - speaking from a Pareto Principle, the sign plus their brand is enough to give the diner what can be called "demand control".

At the same time, the manager will constantly track which dishes get ordered and if there are new trends on the market, without any direct intention to provide any of these. Even if the customers are aware of this, they have no way to influence the manager's decisions as to what the future menu will look like beyond what they choose to order. Next week's special offer and menu will be optimized to maximize sales, while minimizing effort, and if the manager makes the right predictions, customers will be happy even though they were never asked for their opinion.
This is called "demand monitoring" and "demand prediction".

The failure of IT Development

Whereas the Mexican Diner in our example made it clear that they're not a Sushi Bar, a typical company's IT department wants to have full and exclusive control of everything pertaining to Information Technology.
All of this is operating under the assumption that the the demand on a development organization can be met by the available supply.
Once demand is beyond supply, which is a natural consequence of having a successful product with unshaped demand, the organization must choose which demand it will serve and which it doesn't.

There are multiple strategies for dealing with over-demand:

1. Start the "Demand Inflation" spiral and get into a neverending battle about priorities.
2. Encourage a "Bank Run", which will destroy the credibility of your organization.
3. Start "Demand Shaping" to reduce over-demand.
4. Specialize. Stop claiming to do everything. Let others do what they can.

Smart organizations, irrespective of their development approach, will pick option 3 to reduce demand as far as possible, then pick option 4 once that is no longer an option.

Agile Frameworks like Scrum and SAFe will lead unsuspecting Product Owners/Managers into the trap of picking options 1 and 2, which may eventually lead to a failure of the entire organization.

The meta-failure of "Agile"

Managers who look towards "Agile" as ways of improving Time-to-Market and Quality easily get swayed by the claims that "Agile" will improve these metrics, while also increasing employee engagement and customer satisfaction. Hence, they transition their organizations towards agile ways of working. Product Managers get re-eductated to follow "Agile Product Management Practice", which focuses exclusively on short-term supply management and entirely ignores long-term demand management.

As a sweeping statement, agilists with an IT background are terrible at understanding market dynamics and the nature of demand. They only understand the supply side, as that's what they're typically working on. Hence, they can't help on the demand side. Letting a myopic supply-centric approach become your product strategy will be disastrous.

If your "Agile Transformation" has no demand management strategy, or if you think that "let's put everything into a backlog, then pull the most valuable items first" is a demand management strategy, you are going to shipwreck! The bank run is inevitable.

Conclusion

"Agile frameworks have little to nothing worthwhile to offer in terms of demand management. They focus exclusively on managing the supply."

Understanding and managing demand is an important part of managing a sustainable development organization. Agile frameworks have little to nothing worthwhile to offer in terms of demand management. They focus exclusively on managing the supply. Claims that demand control is not required in an "Agile" environment are myopic, made from ignorance - and can lead to catastrophic outcomes in the long term.

Organizational managers and product people alike need to understand demand management principles and practices to steer a product towards sustainable success.  An understanding of the "market" created and engaged by the development organization is essential to determine what the best next steps are.
In some cases, backtracking and demand reduction may be required before one can even begin working with a Product Backlog. Failure to understand this may result in the entire "Agile Tranformation" becoming a no-win scenario for all people involved.

To Explore

This article relies on a lot of shortcuts and makes a number of strong assumptions.
A number of additional items still need to be explored, and I invite the reader to do some of this exploration on their on until I have time to provide additional material.
These items are:

• The applicability of Keynesian Economics to [IT] product development
• The definition of a "good" in the context of [IT] product development
• The definition of "price" / "cost" in the context of [IT] product development
• The Supplier / Consumer Relationship in the context of [IT] product development
• The interaction between product development and non-developmental IT
• Why "Development Manpower" is not a fungible good
• Why a "Supply Limit" exists
• The causes of demand increase in product development
• The causes for starting a bank run on product development
• The effects of a bank run on product development
• Demand shaping in software development
• The effect of demand shaping on development performance
• The effect of having "cross-functional teams" on the complexity of the work
• The trade-offs, benefits and disadvantages of specialization