Recently I had a chance to get back into my product development and product management roots. I do believe that quality assurance, and testing, are highly aligned with product management. So in a series of posts I will talking about some of that alignment, often focused on some key concepts. Here I’ll talk about the idea of “injections” that make sense in the context of product management.

In all of our projects there is a delivery loop. That is the loop of activities that we perform in order to ultimately deliver value. That is what product management, fundamentally, is about: delivering value. The delivery loop is the means by which that is accomplished.

There is a spectrum or continuum to this loop: Discovery –> Ideation –> Elaboration

I’ll be talking about this components in future posts but, for now, just know that you will create various artifacts along this spectrum. Every artifact, from a strategic Product Map to tactical User Stories, will place you somewhere along that spectrum.

A helpful goal is to think of any artifact as having something injected into it. Various injections are:

• Business injection
• Research injection
• Feature injection
• Scenario injection
• Test injection
• Dependency injection
• Task injection

Not all artifacts should allow all injections because they operate at different levels of abstraction.

This delivery loop can be framed as a hunt-inject-spot approach:

The “Hunt-Inject-Spot” approach is one very familiar to product managers and product owners and it’s actually a key point to distributing quality assurance among the delivery team. (This would be as opposed to having a “Quality Assurance Team” which is usually a bit of a misnomer.) Hunting the value is likely what happens during the discovery. Here it should be decided what will add value to the business. Value can be in terms of the typical triad:

• increasing revenue
• protecting revenue
• reducing costs

I would also add another one to that:

• Maintaining or enhancing competitive advantage

Crucially, you don’t specify here. Why specify something — which can take up time and thus incur cost — if you’re not even sure if it will add value? This is where you are answering “Why” questions at a high-level. I should note that this is part of another technique — called the “Why Stack” — that a product team will bring to what are traditionally called “grooming sessions” in the delivery loop. Part of working effectively with hunting the value is having an idea of the “who” and the “how” from the Why Stack. In fact, I talk about the “Why Stack” but in a slightly reframed context.

It’s at the discovery phase that you are going to be doing business injection and research injection. This means you are creating some artifact — perhaps it’s an Epic story in your issue tracking system — that contains the business context and any research around the specific discovery that is relevant for the delivery team to be aware of.

When I say “delivery team” here please understand that means not just product developers, but also designers and developers. I include testers within the ambit of developers. (I talk about that briefly when I asked Should testers become developers?)

Once you are sure something will be valuable (in terms of that triad), then you can start injecting the features, which involves the rest of the team. This is usually the “what” from the Why Stack. When you get to the “what”, you are speaking to what specifically will have to be done to deliver the value. That means your delivery team — again, product, designers, developers/testers — need to work together to create a specification.

Crucially here the “ideation” aspect means that this is where design comes into play as well. It’s important that whatever is going to be developed to deliver value also adhere to a design that is agreed upon in terms of being able to most effectively deliver that value. This is where designers will talk about things like affordances and constraints and where the notion of user experience is extremely important. It’s critical for product developers to make sure there is alignment between designers and developers.

Finally, the delivery team, with product development providing the business and research context and facilitating the necessary features, works to spot the examples. Here the delivery team uses conversations around concrete examples of feature behavior to help understand how features will provide value to the users and thus to the business. This is where user stories start to get created and where scenario injection and test injection will start to occur.

A Modern Approach

Now, a lot of what I said above could be considered somewhat traditional in that even if you use different names for what I describe, you can probably see in the broad strokes some similarity to what your teams do.

Here’s where we update things a bit for a modern context and this is where I’ve seen some product teams stumble.

Effectively, what I’ve described above as we went from feature injection to scenario injection to, ultimately, test injection is referred to as Specification by Example. This describes a set of practices around using examples and conversation to discover and describe requirements.

A spec workshop is where these activities can take place. This encourages product owners, designers, software engineers, and test engineers to collaborate more closely by enabling them to express requirements in a more testable way, in a form that both the development team and business stakeholders can easily understand.

These examples become the acceptance criteria. They are the elements of behavior that we are saying must be in place in order for us to accept this feature. And “accepting the feature” means we believe that the feature does deliver the value that the business goal has been driving us towards.

When these criteria are framed as executable acceptance criteria, that means they are effectively tests. These are tests that could be executed by a human as well as by automation. Since these tests show the acceptance criteria in action, they also serve as documentation for how the application behaves.

You often see a visual like this:

And that’s supposed to mean something. And it does — but not if it isn’t made prescriptive rather than descriptive. Combined with the Why Stack, the above approach is what helps the delivery team to be in a good place relative to that visual.

This is a large part of what product development is all about.

What’s Next?

There are a couple of concepts I introduced in this post. I talked about Specification By Example, Why Stacks, spec workshops and, of course, the various injections. I plan to elaborate on all of these concepts in future posts in what I’m calling my “Product Development” category. For now, this post was simply to level set around some terminology and also to align traditional product development concepts around more modern terminology in the industry.

I also wanted to make it clear that for every artifact that we might consider as part of our delivery loop, and thus of interest to product developers, there is a way to conceptualize how that artifact delivers value by considering what can be “injected” into it.

Stay tuned because all of the above will be expanded on!