The Amplio Artifacts for Product Management

?

I have been using the concepts of stories, features, MMFs (not SAFe’s which has no relationship to Denne and Cleland-Juan’s MMF, regardless of attribution), MBIs, MVIs, and MVPs (both Frank Robinson’s and Eric Ries’) almost as soon as they came out. But I admit to having trouble with all of them for several reasons:

1. Their names are often not intentional revealing (e.g., an MVP can be about a service)
2. They are used inconsistently (e.g., MMFs in Software By Numbers and MMFs in SAFe)
3. They often conflate with each other (e.g., a feature may be an MMF or not)?

All of this (and more) has people misconstrue their meaning.

I have been trying to resolve this issue for literally 20 years.

This morning we (my ACEs and I) did it in one of our working sessions in Amplio University. An Amplio University “working session” is where describe a problem people are having where I am not satisfied with how Amplio addresses it. In this case, the issue was brought up by one of my learners.? She works for a company that creates electronic components, and their creation takes 1 and a half to 2 years for a variety of reasons.? There are many steps in the process and we want to focus on value creation and validation at each one.

The structure we’d been using for product management didn’t work well for this case. Admittedly I had been in similar situations before but always adjusted my way of talking about it in the past.

But Amplio University is not a place where I am teaching my concepts. It is a place where all of us together are creating ways everyone can use where they are. Some people have described this as creating a unified model for creating value. It involves building off principles and guides, not specific practices. But the more the guidance is explicit, the easier it is to understand and use. Hence, we refine the Amplio Model as needed.?

Here's the result of this morning’s session. I’ll walk through the picture at the top given again here.

?

We start with the Product vision. This could be considered an initiative. It is a description of the product or service we are looking to create.? It is based on the values and success criteria of the critical stakeholders' of the organization as well as any constraints they have.

It may be complete with the first step or it may require several steps. Each of these “steps” has a goal. This is the most valuable function we can release quickly. Hence, we call this the “Quick Valuable Release.”

The intention of a QVR should be clear at the start, even though we may not know exactly how to build it or even if it’s viable. QVRs vary in complexity, how sure we are it will create value, their size, the number of skills required to create them, and who it will take to make the value consumable (a term for full kitting).

This blend of knowing and uncertainty means we have to create this QVR with a blend of discovery and creation. Regardless of what or how we build it we want to build in small chunks so that we can create feedback quickly at all levels. This is often called “vertical slicing.”

I used to call these slices MVPs when we were creating new products because I love Eric Ries’ use of the term. But the term MVP has been bastardized so much it is now useless. Instead, think of the pieces of the QVR (a proof of concept / prototype or a functionally complete chunk of value) as having variation in several aspects (see figure).

As you complete these steps you get feedback on the viability and value of the QVR as shown.? The components of the QVR can be either working proofs of concepts or functionaly complete components. Both provide feedback from the customer. We call both of these Minimum Valuable Increments (MVIs).

These MVIs can be subdivided into features.

Features

Features are defined within the context of the MVIs represent functionality that can be used by stakeholders (e.g., customers, users). Features' scope must not go beyond the scope of the MVI they belong to. An Amplio Feature template is:

For <stakeholder> <action to do>. The result will be <ends>. It will be used by <who and means.>

We relate features to stakeholders. There are four kinds of stakeholders

1. sponsoring stakeholders (those who are paying for the development of this feature)

2. consuming stakeholders (those who will be using it directly or indirectly)

3. constraining stakeholders (systems that create constraints on the application being built)

4. development stakeholders (people involved in creating the application).

This provides for a holistic view of the feature. It lets us know all of the people / systems involved in the feature.

A note about outcomes

We talk about the "outcome" of the feature instead of its intention because the outcome can be specified in a very concrete, less ambiguous manner.

Have you ever noticed that there's a difference between telling someone what to do and telling them how they will know it will be done? User stories are telling what to do.

Acceptance criteria specify what it looks like when it is done.

User stories are atomic.

Acceptance criteria are holistic.

The "ends" can often be specified in terms of answering the question "How will I know I've done that?" This gives us clarity without adding any work since that question is eventually asked - we're just moving it to the left.

Note the reference to “<ends>” and “<means>”.?

This references Ralph Keeney’s work where:?

* Prioritize Objectives (Ends):

Keeney argues that the standard approach to decision-making, which focuses on identifying alternatives first, is flawed.?He suggests that decision-makers should start by clearly articulating their objectives, or "ends," as these objectives provide the context and meaning for the decision-making process.?

* Means-Ends Relationships:

Keeney's work also highlights the importance of understanding the relationships between means and ends.?He emphasizes that the means, or the resources and actions used to achieve the ends, should be carefully considered in light of the values and objectives that are important to the decision-maker.?

?* Value-Focused Thinking:

Keeney's "value-focused thinking" approach encourages decision-makers to identify their values and objectives first and then develop a range of alternatives that align with those values.?This approach helps ensure that the decision-making process is not driven by technical or procedural factors but rather by the values and objectives that are most important to the decision-maker.?

In other words, our features are defined to meet some well-specified ends that create the means of use by the stakeholder(s) mentioned.

We can take the decomposition of features into stories in a similar manner.

Outcome Stories

Outcome stories are stories where you specify the end result instead of what a particular customer wants. The intention of what you are building is specified in the MVIs and features. The outcome stories are aspects of these intentions.

The story template is “For <stakeholder> <action to do>. The result will be <ends>. It will be used by <who and means.>”

Note that a feature may have multiple stakeholders involved because many stakeholders may benefit from it. But typically, stories are for one stakeholder.

Decomposing Stories

It is a common problem that teams don't know how to decompose large stories into smaller pieces. Talking about "happy path" and "edge conditions" only takes you so far.

Amplio uses Behavior Driven Design's "given-when-then" format if you need to decompose stories.

This brings in acceptance criteria into the picture along with a definition of done even more.

In summation

I have been using features and stories for 26 years and always felt they had to be massaged a bit. They were a baseline, but an explicit statement of how they were to be used was always outside of my grasp.

Not anymore, I am glad to say.

Thanks for much to all the ACEs who helped create this. There is no way I could have done this on my own. It's just another example of Amplio's ensemble learning method.

#Amplio #AmplioUniversity