In project management, product scope is defined as the realm of features and functions that characterize a product.
But when do we stop to ask ourselves what is a feature? What is a function? Are there other things—possibly better things—that could define and characterize a product?
* * *
People who create products, especially in enterprise cultures, often get stuck in a mode of “feature world” when defining product scope. Feature world is a product creation culture that focuses on producing a lot of product, with great organizational (and business) cost. This turns out to be incredibly dangerous for the organization they work for, as it encourages an approach that does not put customers first.
To resolve this problem and symptomatic ones surrounding it, organizational conversations about product scope need to shift away from features (and functions) and towards something like user scenarios. This doesn’t mean we disregard features for the value they bring to product creation, but it does mean that we shift product definition to something more humane.
Feature World
Feature world is best described by a searching for “feature comparison chart.” You get these sorts of results:
A search result shows that Product 1 and 4 don’t have feature “X”, while Product 2, 3, and 5 do. Repeat for all major, and sometimes minor, features in a product. The product with the most green check marks “wins.”
At face value, it’s a way to easily see what features and functions different products have so that customers (from here on out known as “people”) can make more intelligent decisions on what to purchase. But while the intent starts off positive enough, it turns into something much more sinister.
The Dangers of Feature World
At the organizational level, feature checklists are often used as a sales and marketing tactic for competing organizations that have created similar products. It’s a form of leverage and a means to show differentiation in a saturated, competitive market space. It’s “proof” that Product A is better than Product B.
Over time, and as a result of this tactic, people begin to expect, and demand, features in your product. They begin to demand features, whether in competitor software or of their own imagination, as solutions to their problems.
This situation creates a negative feedback loop, and it goes something like this:
- People demand features
- Service teams pressure product teams to build features
- Product teams must build features or they will “fail” the organization
- Repeat — until you have a bloated product that bleeds people that use it
This situation is an issue which is both unethical and cultural. It’s a cultural issue because it influences the actions of multiple groups of people within an organization. It’s unethical because organizations rarely put effort into addressing this pressure, which leads to a mentality of “build, build, build” with disregard to why it’s needed by the people they serve.
Why do organizations rarely put effort into addressing it? Because features are easy. They’re easy to manage. They’re easy to estimate costs, time, and resources. They’re easy to focus on and define as an incremental step to building a product. They’re easy to create without validating why you need them in the first place.
Features are also something everyone knows what to do with. You can plan them out for an entire year, which appears great, because it’s an easier way to budget at an organizational level. It’s also easy to make it appear like your organization is doing things. Doing things, for the sake of doing them, makes your feature checklist longer than your competitors. This further amplifies the negative feedback loop.
All of this ease, of course, comes at a great organizational cost. This cost comes in the form of many cultural symptoms. Each one of these symptoms could have an entire article associated with it, but here’s a list to get an idea.
Defining products by a set of features…
- doesn’t encourage a people-first product creation process
- inhibits a “big picture” view that would have created a strong product vision; feature X may not fit with an experience of feature Y
- creates a reactionary “no” to anyone daring to question product scope
- promotes waterfall development over agile, and the cynicism that comes along with being waterfall yet calling your organization agile
- creates an internal culture of competition and empire building, making it difficult for user experience teams to do their job
- creates situations where development teams are fed work simply to keep them busy
- emphasizes “rework” as a bad thing (is learning and adapting to the needs of people really so bad?)
- limits the creative potential of your user experience and design teams
- prioritizes the speed of building a product over the learning about the people you serve
Feature World Is Not Business Value
The point of understanding the culture of feature world is this: people who might buy your product can instinctively smell the reek of a product created in feature world. When people smell the reek of feature world, they run. They run far, far away. People expect more in today’s world, and they have a large amount of options to choose from. This behavior of people has one major takeaway for organizations with a culture of feature world:
More features do not equate to more business value. Instead, more features tend to degrade the experience of a product by putting so much into it that it loses its chance at fulfilling anyone’s expectations. To have business value in today’s world, defining products by a set of features doesn’t work.
So what does?
User Scenarios: A Possible Candidate
To introduce user scenarios, it’s best to give a fictitious, generic example of what software creation by feature looks like.
Creation by Feature
Let’s say you’re creating software for event coordinators. You start with your outdated software that you built 10 years ago. You have a small set of features you personally want to pull forward, but a lot of it you know people don’t even use frequently. You also research many competitors software and notice that a lot of newer ones have these features:
- A calendar to track your booked time
- A signup form for clients to book your open time
- A form to collect general inquiries
You also notice a trend: none of the competitors use the latest, cool technology. None of them sync with the cloud. None of them remember your past clients and give you a graph of how much you charge over time.
Between yourself and your competitors, you have now scoped your product to #insert_number# major features. Well done. Or so you thought.
You build, and when you’re complete, you “win” because you have more green check marks than any other product with the latest, cool technology. Until you don’t, because what you’ve just done is build a set of mechanical interactions that have no relevance or meaning to the day-to-day habits of the people that you’re trying to help.
Creation by User Scenario
Instead of looking at your old, or competitor, software, you (rightfully) say to yourself: “Forget all of that garbage. The best way to build great new software is to deeply understand event coordinators as people.”
So you cold call some event coordinators until one of them agrees to let you shadow them for a week. In return, you offer them a discount or extended free period on the software that you’re creating. You now have a partner. Here’s what you learn over your week:
Your partner is an event coordinator who regularly gets client calls and creates three price-point versions of an event to share back with the client. They create these versions for the best chance at “getting the sale.” To create an event, the coordinator starts with details gathered from a short interview with potential clients, and further enhances it with details on resources found on various event supplier store websites.
The above situation is a user scenario.
A user scenario is a phrase that captures the who’s, what’s, where’s, when’s and why’s. In this way, it is related to the methodology of research, journalism, and investigation. Those methodologies are all about storytelling, and great storytelling is key to the success of a great product. Similar to the five Ws is the user, purpose, context methodology, which is an alternative storytelling method that can be used to rally product teams around scenarios.
A user scenario is also about capturing the current behavior model of the person you’re building a product for. Do they have the ability to do something? What motivates them to do it? Is there a trigger that creates the urgency to do it? Understanding the behavior model of people can give insight about the gaps of their expectations from a product and also hint at what more you can do beyond those expectations.
From User Scenario To Product
So how do you build a product starting with this scenario? How do you enable people to design events, and manage a list of resources whose prices are dependent on their choice of suppliers all around the web?
First, you recognize that the scenario enables you to brainstorm product design possibilities. Go crazy, and think of any way you might resolve the scenario no matter how seemingly stupid or even outside the realm of software. You could introduce carrier pigeons as a novel way to send event plan details back to clients. That would sure be memorable for people, even if perhaps not viable.
The point is, product design possibilities are also features, but the enormous benefit that you’ve given yourself is that you’ve scoped your product in a way that enables you to experiment, prototype, and test towards features that resonate the most with people.(You can do this super cheaply, too. In a super short time frame).
When you have in hand what resonates with people, you’ve just given a billion gold bricks to marketing and sales. And you’ve just broken the negative feedback loop of the feature checklist. Your combination of positively delightful features is a unique product offering that has market competition of zero.
If the above wasn’t enough, another major benefit of this is that you can cap your product scope to this one scenario while you figure out what features actually resonate with people. To stress this point: you, as a product team member, have the choice to scope your product indefinitely with one user scenario. This has pretty large consequences on how you resource your team over time at your organization.
With one user scenario as product scope, you’re a blip on your enterprise organization’s financials radar. You’ve just given yourself an easy green-light project with a team the perfect size to handle the scope.
In familiar development terms, this is the true and original agile. Keep the team as diverse, small, and nimble as you need to in order to find just the right combination of features that delight people. No need for project initiatives in the millions of dollars of investment. A super low-risk approach to the big wins.
An Unwritten Future
While event coordinators may not be the epitome of people on the planet that need help, this was just an illustrative example.
User scenarios seem like a pretty clear path forward, but using these within an organization tackling more critical issues, as a practice, is not something even close to textbook.
Who has tried something similar to this? How did they do? What did they try? What was their situation? What types of personalities within their organization did they have to collaborate with? What existing cultural barriers were there?
In absence of information, we can brainstorm other potential starting points for you to try in your organization:
- user goals
- user workflows
- user tasks
- product experience criteria
- product vision principles (sort of the same as just above)
- design motifs
The theme of this short list is that all items are more human-centered. They give people who create products a common language the same vocabulary, or a shared ground that enables organizations to prime a product for success. But product success is not the where success begins or ends.
What success truly looks like are the daily conversations focused on understanding the people that your organization is helping. What about the user scenario(s) do you know? What don’t you know? What are you going to do to find out what you don’t know? How does that information feed back into the product development cycle? If these are the questions your organization is asking, then you are heading towards success.
Cover photo courtesy of Kyril Negoda under an attribution creative commons license.
