Feature Injection is a very helpful process framework created by Chris Matts that is not explicitly used as much as it probably should.
I suspect the main reason it is not adopted more is because people don’t really understand what it’s all about. There are several articles and blog posts that explain feature injection, but for whatever reason many practitioners don’t find them easy to understand. Examples of some of those references include:
- The InfoQ Article Feature Injection: three steps to success by Chris Matts, and Gojko Adzic which tends to be the most referenced article.
- Chris’ 2009 Real Options Comic Books which includes quite a bit about Feature Injection that he distributed at Agile 2009. I’m proud to admit that my acreage was the inspiration for the setting in the comic books.
- Liz Keogh’s blog Post BDD in the Large which describes Feature Injection in relation to Deliberate Discovery, Real Options, and BDD. I admit I personally get a little wrapped around the axle with the six layer hierachy, but that’s probably more a reflection on my perspective on hierarchies than Liz’s description.
- Jesus Gil Hernandez’s post Feature Injection: From Outputs to Inputs does a good job of describing the idea of working from output to input which is a key aspect of feature injection in how it relates to the use of traditional business analysis techniques..
If you have not read these yet, I encourage you to give them a shot. You may find that they make perfect sense to you. If not, here’s my attempt at providing a more useful explanation.
Feature Injection is based on understanding the value an initiative intends to deliver, delivering the features that provide that value, and building a shared understanding about those features primarily through examples.
Let’s look a little closer at the three key ideas.
- Identify the value
- Inject the features
- Spot the examples
Identify the Value
Feature injection begins by creating understanding about the business value an initiative is trying to deliver (in other words, why are we doing it in the first place). In a for profit organization, an initiative delivers business value when it increases or protects revenue or reduces or avoids cost in alignment with organizational strategy. In a more general sense, I like to gauge the business value of an initiative based on whether it helps an organization meet one or more of it’s objectives.
For example, let’s say you are working at a health insurance company facing the prospect an increased claim volume but they would prefer to not add staff too soon. One area they feel would help them process more claims with the same staff is in the claims intake – they still receive a considerable number of paper claims which have to be entered in to the claim processing system. With that in mind, the health insurance company establishes an objective:
Reduce the number of paper claims received from 1000 per week to 500 per week within six months.
Once you understand the objective you can identify a solution you think will meet that objective, and identify the assumptions that underlie your belief that solution is the right one.
To continue our health insurance example:
Building and hosting a website where single provider offices can submit their claims will help us reduce our paper claims.Assumptions:– Most of our paper claims come from single provider offices– Most single provider offices have internet access– Most single provider offices do not have medical billing systems– If we build a website, our single provider offices will use it.
Inject the features
Once you understand the value you are trying to deliver, and the assumptions that impact that value, you can use that information to guide what you do next. You want to select chunks of value (which I will call features ) that allow you to make progress toward meeting the targeted objectives or help validate assumptions. Which aspect you focus on first will depend on how far along you are in the initiative. At the start, you will most likely spend more effort on validating assumptions (you can also think of this as reducing uncertainty) and follow up with delivering features that you know will deliver the value you seek.
This is where analysis techniques and the idea of working from output to input come into play, especially those representing displays of information or reports that stakeholders are looking for in order to answer some questions or make some decisions or support a broader process.
Once you understand the outputs, you can work backward to figure out what processes are needed to produce those outputs (including the rules that act in those processes) and the inputs needed to create the outputs. You are effectively performing analysis in the opposite direction of development, which tends to bring in the inputs of a system first, then build the process, and finally create the outputs. Said another way: because you are pulling value from the system via the outputs, you leave a hole at the beginning of the system into which features are injected. That’s how the name feature injection is derived; as we pull business value from the system, we inject the features that create that value.
For our health insurance example, the team would probably first undertake some actions to validate the key assumptions mentioned above. If those assumptions prove correct, the team can then model out what the online claims system would look like (rough wireframes should be sufficient) and start iteratively building the system, collecting feedback and frequent increments throughout the process.
The key point here is that you identify value first, then iteratively identify the features that you need to deliver it. Don’t brainstorm a big list of possible changes and try to figure out what each feature could contribute to business value, focus only on those features that directly lead to satisfying your objective.
Spot the Examples
We typically use models to describe the outputs and processes and the inputs used to create them. These models are helpful for creating shared understanding with everyone involved in delivering the features, but they are rarely sufficient. One way to make the overall understanding of a model clearer is to add examples. Examples serve two purposes: First, they provide concrete guidance in very specific situations to people who tend to ask “Yes, but what about this situation?” And second, examples give the team a way to test the models and make sure they account for different situations that may occur.
The thought process surrounding feature injection is a huge influence on how I approach all projects, and while I very rarely mention the name to the teams I’m working with, I’ll often introduce the ideas. Most of the people I talk to say things like, “Yes, that makes a lot of sense. Why didn’t we do that before?” or, “Yeah, we do that, with these few tweaks.” Starting with the value you want to deliver, using that value to decide what feature to build next, and describing that feature through the use of real life examples, proves to be a simple, effective way to build the right thing, and not build things that aren’t necessary.
I like this summary, but I disagree with “chunks of value (which I will call features)” – features don’t bring value – they are outputs of the delivery process, not outcomes. It’s much more useful to think about chunks of value as outcomes or impacts, and features as chunks of outputs that can potentially lead to that value.
Hi Gojko,
Thanks for reading it and for your comment.
I’ll admit I struggled with what label to attach to those chunks of value.
I picked features because it tends to be a commonly used word (albeit one with a lot of baggage) for that purpose. If anything, I suppose it’s better than using “user stories” 🙂
To be technically correct I could have called them CoV or Quantums of Value but I find it’s those type of technically correct, but obscure, word substitutions that lose people who don’t think deeply about this type of stuff and just want to figure out how they can use it to their advantage.
My point was that features are chunks of work by the delivery team, which itself isn’t valuable. Those features lead to changed/improved/new capabilities but capabilities only increase the potential for some value to be delivered, they don’t actually deliver it (for example, if a button is developed to pay money in, but nobody ever presses it, there is a capability for value but it wasn’t achieved).
I don’t mind the concept “chunks of value”, and I think outcomes or impacts are good labels for chunks of value – changes in the way people work/behave.
I’m struggling with the statement above that “features are chunks of work”. I thought features were what the chunks of work resulted in – as in “implemented feature” where the work is the build variety, or a “logical feature” where the work is the design variety.
As to “value” – surely we nearly always use that single word as shorthand for “potential/latent value” ? … And there are circumstances when a capability delivers value even though it is not used.
Could you say more about why you believe it’s “much more useful to think about chunks of value as outcomes or impacts, and features as chunks of outputs that can potentially lead to that value”?
Joe – because more features isn’t necessarily good. More features = more work put in = more complexity = resulting system takes longer to test and is more expensive to maintain. So focusing on features leads to focus on increasing the cost sunk into software. It’s much more effective to focus on what people buy for that cost, instead of the cost itself. Outcomes and impacts are hopefully the reason why someone is asking for those features. Good product management is the art of making choices so that people get the most outcomes for the least investment (so most outcomes for least features)
Thanks for this post. Feature Injection seems to be the funniest name for a simple and not so new, yet rarely truely applied idea: Working your way from the problem to the solution, aka focusing on What rather than How. I like the explanation of creating a hole with the What and then filling it by injecting a feature (the How). Briefly looking at the Real Options Comic ebook, it brings a few ideas together that I’ve been bringing together in the past weeks, unaware of these writings… So not as new as I thought, but on the other hand, obviously I wasn’t way off track. In my words, the testable aspects of the system are essentially the specification. There is more to requirements, however: The stuff that can only be expressed in terms of the application domains. And in fact the question, which descriptions to write down besides the testable behavior. The application domains are rarely given the attention they deserve. You can tell when expressing examples is hard work, because there is no appropriate vocabulary for individual entities, states and events.
I agree with Gojko (and I first heard it from Jeff Patton) that features are not equivalent to value, or less output may mean more outcome. It’s more like the seed (the feature) and the harvest (the value), but not like corn farming–rather like precious, rare, and capricious plants.
Hi Kent,
I saw Chris talking about Feature Injection recently – I think it’s a great idea, but like you say, I think it’s a bit tricky to pick up. Chris also commented that he wishes he’d called it something better!
For my money, one of the key things Feature Injection gives you is a conscious process of considering the various options to achieve a given objective (or to deliver a perceived chunk of value/benefit). I’ve tried to incorporate this conscious process in my own work as a agile BA – I call it “Options Engineering” (because I figure if I give it a name then it might start existing as an activity!). In particular, I always try to consider the “do nothing” option – which is often a good option if the cost of doing something is likely to outweigh the benefit.
More details on my blog at http://www.its-all-design.com/business-analyst-designer-method/