One of the ideas that I’ve been thinking about a lot lately surrounds the notion of feature value in agile teams. It’s driven by this typical value flow of agile work—

• The Product Owner drives the highest priority User Stories (Features)
• The team delivers these to the ‘Business’ and gains sign-off that they’ve met their commitment
• These features are then pushed to the Customer for use

Agile is terribly wrapped around the axel of value-driving functionality. It is one of the primary responsibilities of the Product Owner, Business Analyst, and Tester (among others) to write stories that connect the described needs to customer value.

The Product Owner is continuously considering the usefulness, the popularity, the compelling-ness of features. They are gathering insights from stakeholders as they craft the definition of each User Story and how it relates to the overall feature they’re defining. One of the reasons for this is simply due-diligence from a business perspective. Another revolves around the base needs of their team.

Your ‘A’ Team

You see, a primary responsibility for the Product Owner in this sense is to treat their teams as a highly-skilled and specialized resource. For example, a high-caliber swat team. You don’t send a swat team out to police burned out traffic signals or guard child crossings. Not that those activities aren’t important, but the world has many who can do those jobs well.

No, your team is a highly trained and highly skilled group. You need to be considerate of their time and energy. You need to give them work that will challenge them, delight them, stretch them, grow them, and encourage them. In a word, you simply can’t waste them on the mundane or more importantly the non-valuable.

So every choice you make in seeding work into their backlog needs to be carefully considered.  Many if not all Product Owners, solely consider the business-side when it comes to developing and prioritizing stories and features. But what about their team’s needs? They also need to consider the impact that the features will have on their teams’ morale, trust of you and your skills, and overall understanding of your strategy.

Too Laissez-Faire

I see the definition of Feature Value to be a much richer landscape than simply saying this feature or story is #23 on the Product Backlog hit parade. Trust me, that’s where it belongs…so now go and execute it.

And I see way too many Product Owners not taking a holistic view towards their prioritization and selection of stories. It’s unfortunate really, because adding an appropriate level of nuance is their job.

There are two key areas that I want the Product Owner’s to improve in—

1. Explaining the WHY behind each and every Feature. Why is it important? To the organization? And their core business strategies? Why is this team being asked to deliver the Feature? Why has this specific set of User Stories behind the Feature been selected as crucial for delivery?

And

1. How will the Feature success be MEASURED? How will the Product Organization and Product Owner be measured on the Features worth estimation? What are the critical KPI’s for this feature? How was this data derived? Will usage data be collected from the Product to confirm?

Let’s explore each of these in turn…

What about WHY?

So, I think the first question our Product Owners need to start answering is ‘Why’. Why are we picking this feature? Why do we have to implement the described functionality? Why is the customer asking for it—what problem are they trying to solve? Why have you prioritized it this way—over these other five features? Why is it important? Why can’t we “skip it” and work on technical debt—as the application is becoming impossible to support?

And beyond the questions, which are certainly segues into insight, what’s really important here are the answers. Giving the team the ‘Why’ behind your decision-making and trade-offs is crucial to helping build great applications.

The answer to why can be un-compelling and demoralizing, for example, we’re doing this because our Group VP Bob said to do it. Period! Sure, that’s the answer, but it gives no insights that the team can leverage in producing great products or feeling good about said activity.

Or you can give the team competitive landscape insights and insights into your customer needs analysis that have led you to the conclusion that this feature is in the Top 10 of high-impact needs for your customers.  And you can communicate this to your team in the context of the customers’ problem—so that they approach the requirement from a solutions design perspective and not simply implementing what you asked for.

A wonderful resource to help inspire you to the importance of Why is Simon Sinek’s TED talk on the subject of ‘Why’. It’s only 18 minutes, so take a peek…

 

Value Estimated…and…Measured

Beyond why, the second question to be answered relates to value and measuring it. How do we as Product Owners plan on measuring the value of this feature once deployed? What are the critical success factors in customer usage, customer acceptance, and quality levels? Do non-functional requirements come into play—such as performance and security considerations? And if so, how specifically will we measure sufficient support levels both prior to release and then late, in the customers’ hands?

I find that many Product Owners don’t sufficiently define measures for their acceptance criteria. Very typically this will result in ROI, i.e. in raw sales or in usage & adoption metrics. This is particularly easy to do if you’re product is delivered as a SaaS. But it’s possible to do no matter your product delivery mechanism.

Why do it?

First, it indicates how well the team is truly achieving their business value goals. It’s not some sort of guess, but it’s derived from real usage, adoption, and sales data. And the team should pay attention to this when developing (the target) and when delivering (actuals) functionality.

But more importantly, it also is a report card for how well each Product Owner’s decision-making is determining and driving their valuable team towards delivering business value. Just as the team needs to be accountable for their estimates and efforts, each Product Owner should be estimating (placing items on the Backlog) and being critiqued on how well they guessed at ultimate customer value.

Wrapping Up

I apologize for meandering a bit in this post. The critical points relate to Product Owners having two critical responsibilities—explaining the why behind their decisions (their thinking) and measuring the effectiveness (value realized) of their decisions. And then having the responsibility to learn from their measures and decision-making results, reflect on their actual performance and continuously improve.

And by Product Owners, I don’t just mean the PO proper. I also mean the Business Analyst, Tester, virtually anyone who contributes User Stories describing what will be built and how we’ll measure it.

Simply put: Focus on the Why and Measure the Value

Thanks for listening,

Bob.

Don’t forget to leave your comments below.