Outcome Focused Feature Design: A Paradigm Shift To Improve Enterprise Value Delivery

Image for post
Image for post

Features are not vertical groupings of user stories. They must be designed so they either serve internal functions or drive customer experiences; they must be outcome focused.

Short feedback loop can prove its real use when based on the point where actual customer value is created.

The first week was all discovery. It was rather interesting! While the coaches got plugged into the delivery teams, an analyst and I sat across from senior project leaders in several meetings who explained their current state of affairs. We were told that some teams had started sprinting and were at sprint 6. They had been conducting all sprint events diligently and scrum of scrums to enable cross-functional interactions. All great signs! However, why were they unable to showcase working software to the business? The next question we asked the project leaders was — what have the teams been showcasing during sprint demos thus far? The response we received was that the teams have been demonstrating design and working code… and there it was , the moment that made me infer my meaning of the aforesaid.

What is the goal of agile delivery? Is it to run all sprint events and scrum of scrums diligently? Well, what is the use of running them diligently if the teams were only putting two week time-boxes around their waterfall way of delivery? While these are forums that help teams self organize to achieve the goal, the actual goal is to get business outcomes out of the door as minimally and as quickly as possible. Easier said than done! This required a complete mindset shift across the program from “when do I get the whole thing?” to “when do I get to see the smallest end-to-end use case through working software?” — a complete culture change. However, with executive acknowledgement of the need for change, desire to change at the frontline leadership and team level, a solid operating model in place, targeted training and coaching, and continuous reinforcement from the leadership on the need for shift, we believed it could be achieved through making small changes every week over a period of time. During the course of the next few weeks, the rest of the transformation team aimed at getting the program to the target state, which was still not detailed at that point. I, along with the analyst, focused on developing the operating model that, when completed, would inform the target state.

Image for post
Image for post

As you can guess, the train was on the move and we had to lay a track in front of it, if you will. Therefore, we had to be quick and deliver an MVP of the operating model. It was also important for us to show that we practice what we preach! However, we all knew what the problem was at a high level, but didn’t quite know what the root cause was. We decided to apply 5 whys on this matter to get to the root cause and a plausible approach to solve for it.

Q-1: Why were we yet to produce something demonstrable?

A: The transaction journey was highly complex. The transaction had to go through multiple products, each of which did its part to determine a portion of the end outcome, or process and provide inputs to the next product in the value chain. However, there was so much code being written, so much testing being done within individual product teams.

Q-2: Then, why were we unable to demo something integrated across the teams?

A: The features were being built within the teams and were not fully aligned across the products. Could it be a prioritization issue?

Q-3: If the problem was with the dependencies across the products not being prioritized together, why didn’t we just do that?

A: Each of the product teams had its own product specific feature goals and priorities. The feature definition was being done specific to the products. Wait a minute, but did each of the products produce a customer outcome or produce integral components of it? Where was the customer outcome being produced? Did we just get to the root cause of the problem in 3 whys?

The delivery teams were delivering whatever was being defined as features and user stories. So maybe the problem was with what was being asked of them — what we were defining as features. After all, what you feed the machine is what gets processed, if you will. The simplest definition of “feature” is something that appears or you wish to appear on the end product or outcome, that provides an ability to interact with the product/outcome and derive an experience that hopefully creates a “positive moment”. For the sake of simplicity and making it more tangible, if the outcome is a watch — display of time on it could be a feature, count of seconds could be another feature, display of date could be another feature, and count of split-seconds could be yet another feature; these features could be different in an analog watch. As you might agree, in order to look at your watch and tell time, you don’t need all of them; you could do well with just the first and remaining features slated for future iterations. To build the features incrementally, they have to be written to be incrementally deliverable and the product teams that form the value chain have to be provided with common feature goals so that they are prioritizing the dependent user stories for sprints in a way that a testable functionality is produced at the end of the sprint. Optimizing the point of arrival by appropriately defining our features and user stories, sequencing the user stories to deliver outcome focused features and prioritizing them for the delivery teams is therefore highly important if we look at it from this point of view.

Putting things in context, consider a value chain that produces a “bill of services” as an outcome. Defining features as what the customers want to see on that statement might be more relevant than defining features as things that the enterprise software products need to do as activities, as their part, to produce the end outcome. In other words, the activities are meant to produce the features on the outcomes, and are not features or outcomes themselves. This is a very common pitfall when defining features and user stories for product teams. Defining features in product silos might work if the product itself produces an outcome that customers consume. However when it comes to complex value chains, following the same method can prove to be causing lamentable integration backlog and the more we procrastinate getting to that backlog, the more risk we assume for the overall program.

This approach of outcome focused feature definition sets common feature goals across the value chain. The common argument is that there is nothing valuable we can produce across such a complex value chain within a sprint or 2. If it cannot be delivered within a sprint or 2, we have to see if it can be sliced further by increasing the specificity of the feature being requested — for e.g., the feature can be requested for a custom input scenario; feature could serve only a specific group of customers. Even if it is for as small a number as 10 customers, it is still demonstrable value. It may not be an MVP yet, but it sure could be seen as an increment of it. The point that I am trying to drive home with this is that we need to try and iterate on outcomes and target customers as opposed to product specific functionality in silos.

This approach of setting common outcome focused feature goals across enterprise software products not only helps us fail fast with respect to integration but also helps us gain stakeholder confidence, because it lets us demo “working software” as opposed to “working code” that we promise will integrate eventually. Additionally, it bakes in the lamentable integration effort that we would be otherwise back ending if we were to build features in silos, specific to the products. Thus, “outcome focused feature definition”, became the pivotal driving factor of the operating model that was built to inform the transformation efforts. While it set the initial direction, we focused on improving the flow of work to be LEAN, structuring of teams to be newly stood up and aligning them to the value chain and enabling relevant reporting around delivery in the following weeks and produced the subsequent iterations of the operating model.


Last but not least, outcomes themselves need to be designed by understanding the customers, their pain points, their wishes , their unmet yet unrealized needs with a notion of: “Don’t design your customers, understand them”. It is important to have that customer centered design thinking while defining the outcomes through features. There is a whole lot to say just about customer centered design thinking. This article in itself does not cover much of that. However, I hope to write my perspective on how to achieve that in the context of large scale enterprise value delivery sometime soon!

Written by

agile, digital transformer. product, service designer. ai aficionado. foodie, traveler, reader, complexity thinker, philosopher, photographer. views are my own!

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store