Feature-thinking does great things for architecture and system design, but if not kept in check, teams can completely miss the human and value factors.
Let's look at an example:
A pizza company hired a team to build a smartphone app to order pizza. The pizza company wants to focus more resources on creating quality pizza vs. answering the phone. They want to reduce the number of calls to the pizza shop by getting customers to order via the app. They want customers to prefer using the app vs. calling the pizza shop to submit an order.
So the team gets to work. They start by asking, “OK. What do we need this app to do?” Their requirements approach begins by brainstorming features. They think of things like: Profile Management, Order History, Build Your Pizza, Payment Wizard, Notifications, etc.
This may seem like a logical way to begin, but this feature-focused mindset often leads teams down the path of over- or under-engineering their solution. It creates a risk to solution/product quality.
The problem is not the feature-thinking itself, but what gets shoved aside when features dominate the thoughts and dialog of stakeholders. In most cases, value-thinking sits on the sidelines—we forget about the value the solution brings to our users and our organization. Let’s follow our pizza shop example to provide some context for 3 pitfalls of “feature-thinking” to avoid.
1) Don’t let “feature-thinking” consume the problem/opportunity.
The team is NOT building a pizza ordering app; they’re solving a problem. What might happen if the team remains focused on the app and its detailed features instead of the opportunity to make a better pizza by reducing phone calls? Teams might:
- exceed what is needed from a minimum viable product perspective
- get distracted by secondary features and compromise the quality of the features that have a direct impact on the problem/opportunity
- waste time and money
- create a product that has so many bells and whistles that users are overwhelmed, don’t use the app, and continue to call in their orders
Features can help teams discuss the problem or opportunity at a high level, and detailed feature thinking is critical to great software engineering and architecture, but features by definition are a functional capability of the solution. When teams operate in a solution mindset, they tend to jump to technical details. Especially in the early stages of a project, describing feature usage and value context without doing technical design is the key.
When discussing features, be sure to ask: What part of our problem will this solve or what aspect of our opportunity will this help us take advantage of? If this focus is lost, value is compromised.
2) Don’t let “feature-thinking” devour the customer.
“Whom will it benefit and how?” This question MUST regularly be asked during feature-focused discussions. Because feature-thinking focuses on the solution, teams need user advocates with a value-thinking mindset—someone who will help the team brainstorm feature ideas by focusing on customer needs.
When our pizza shop team member starts the requirements discussion with, “What features does the app need?” A BA can reframe the question by asking, “What do the customers need the features to do?” Or better yet, “What is critical to achieving the vision of customers wanting to use the app vs. call?” It’s not the feature that’s important! We need the team to focus on the results of the feature and how the results serve the customer need.
When I see a team entering this danger zone, I like to ask them to step out of the feature for a moment. I ask them to brainstorm two different types of scenarios—scenarios that meet the user’s needs and scenarios that do not. Getting the team to brainstorm many manifestations of the feature helps the team see the feature from a user and value perspective.
Back to the pizza app.....let's look at a feature called "notifications." What ways would this feature enhance the user experience, negate the user experience, or have a neutral impact on the user experience? We may generate ideas like this:
- As a customer, I want to receive a notification that my order has been started, so that I know it is in progress.
- As a customer, I want to receive a notification when my pizza is in the oven, so I know the progress of the order
- As a customer, I want to know when the delivery car is within 500 ft of my house, so I can make sure the dog and kids are out of the way when I answer the door and have a less stressful interaction.
- As a customer, I want to receive a notification of when my favorite pizza is on sale, so I don't miss an opportunity to save on my favorite meal.
- As a customer, I want to order the pizza from a notification of a promo so that I don't need to tap too many times to act on the promo notification
- As a customer, I want to be able to ask the app to remind me of a promo when I read a notification and mark the notification as “remind me in ____.”
All of these scenarios have different architecture implications for the notification feature, yet not all of them bring value to our pizza shop customer or our pizza shop workers in the context of our goal to minimize calls. Which ones add value and which ones don’t?
How would you analyze and prioritize features based on what matters to the customer? What do they expect at a minimum and what will they not even care about? This is minimum viable thinking at work!
3) Don’t let “feature-thinking” eat the pizza. (Focus on value!)
If we lose focus on the problem we are trying to solve and the customer needs we are trying to meet, then our features will eat our pizza—they will consume all of the value the team hoped to provide for the organization and its customers.
Features maximize value when they align with and are prioritized based on the core mission of the organization and the needs of the customers. Keeping this focus will keep you in check and prevent you from under- or over-engineering solutions. It’s all about creating really good pizza, happy customers, and a thriving business.
In many cases, feature-thinking can be a great place to start, but beware of the risks. Don’t minimize the value of a product or solution—put the human and organizational goals back into the requirements.
Do you start your requirements process with features? If so, here are a few questions for you to ponder:
- How do you avoid these three pitfalls and keep your team focused on organizational and end-user value?
- How could you change your requirements process to begin with value-thinking?
- What would a value-driven requirements approach look like?
Please leave your answers/comments below.