Author: Angela Wick

Get Off the Documentation Hamster Wheel

Written by Angela Wick on October 6, 2016. Posted in Articles.

In a recent BA Times article, I suggested that most teams spend too much time on documentation.

I even boldly proclaimed: “When planning, elicitation, and analysis are done well, documentation becomes simple and speedy.” I think most people agree in theory. They are hungry to reduce documentation and speed up their requirements process, but they keep on documenting. They stay in the hamster wheel and keep writing and reviewing and updating their documents over and over again.

Reducing documentation is a real struggle for individuals, teams, and organizations. They want to jump off the wheel, but they don’t know HOW! They ask me:

• What should I be documenting? What should I remove from my documentation?
• How do I know when it’s good enough?
• What does lightweight documentation mean?
• How will my developers get the code right if the details are not in my specs?
• How do we know if all of the requirements have been met if the documentation does not include detailed requirements?

Or they point fingers:

• The PMO/BACoE/CIO makes me fill out all of these templates.
• This is what the stakeholders expect.
• Audit requires all of these details.
• Legal wants this paperwork.
• The local/state/federal/international/alien planet government needs these documents.

Two New Mindsets

That hamster wheel is going to kill you (or more likely, stunt the growth potential of your organization)! Solving your document dilemma requires two significant changes in mindset. First, teams need to let go of “one size fits all” and replace it with “adapt or die.”

Every project has unique documentation needs. It’s ineffective and inefficient to apply the same approach to every project—teams need to adapt. Would you document a pizza delivery app the same way you document a life-saving medical device that will be implanted in a human body? No. Even within an organization, documentation approach should vary for internal vs. external users, new products vs. upgrades, bug fixes vs. major releases, process-based projects vs. system-based projects, etc.

While it’s important to adapt your approach, great requirements can be consistent! Consistent in explaining (without vague and mushy words) who the users are and what goal they are trying to achieve. Consistent in providing what context, data, rules and quality expectations are in play to create value for the end user and customer.

That leads us directly to our second (and most important!) mindset—teams need to “Let Value Be the Judge.” Instead of pointing fingers and passively accepting status quo, VALUE should be the judge of every proposed piece of documentation.

More is not better! We should identify the right requirement set: does this provide value, what is the thinnest/lightest version of documentation we can use to deliver value, will these requirements lead to a solution that over or under-delivers on value to the customer?

5 Factors to Evaluate Documentation

Consider these factors to evaluate each piece of documentation:

• User: Think about who will be using the documentation and how they will use it? What level of detail do they really need? Discuss documentation reductions with users and experiment.
• Lifespan: Consider how long the information will be used and how long it will remain accurate. Is the lifespan so short that the document provides zero value? Is accuracy so important that the document should be created just in time? Should the format of the documentation change based on the lifespan?
• Cost: Think about who would be willing to pay for this information and why. Estimate how much it will cost to generate the documentation and determine if the cost aligns with the value. Is the process to create shared understanding of requirements more valuable than the document itself?
• Fear: Explore the possibility that fear motivates excessive documentation (aka Cover Your A**?) Does that fear-based mindset boost solution value or does it increase time and cost?
• Format: What is the most efficient format to deliver value? Do your requirements really need to be written in a template? For some, yes! For others, no. Do they really need to be entered into a tool? What is driving the template or tool usage, governance or better requirements? Depending on your project type and your team structure, documentation might be post-its on the wall, drawings on a white board, prototypes, notes on a napkin or even a series of discussions/demonstrations.

Above all, strive to create an environment that allows for constant collaboration and meaningful dialog with developers. Change the mindset that thinks requirements are DONE when we hand them off to our techies. Instead, be in it together from start to finish.

But What About Audit?

I am not suggesting that you ignore or refuse to cooperate with protective entities like legal, audit, best practice (Center of Excellence/PMO) and regulatory. Instead, I encourage ongoing and collaborative conversations about documentation. Understand what they need and why. Work together to determine the thinnest/lightest version of documentation to meet their needs.

Are you ready to jump off the documentation hamster wheel? Instead of spending all your time updating requirements and managing sign-off, focus on helping your team think strategically about the value you are providing to end users and the organization. Details fall into place with minimal documentation when teams collaborate continuously. Conversations rooted in value build shared understanding, which alleviates the need for excessive documentation.

Please leave your comments below.

3 Reasons Value Needs to be at the Center of Your Project Triangle

Written by Angela Wick on September 6, 2016. Posted in Articles. 1 Comment on 3 Reasons Value Needs to be at the Center of Your Project Triangle

Over the years, I’ve helped many teams find success by identifying and removing roadblocks.

One roadblock that seems to be appearing with greater frequency is “project prominence”— an emphasis on the project over the product or solution being delivered. Teams spend so much time and energy debating, controlling, managing and measuring the project process, that they lose sight of the product and the value the project is looking to deliver. The needs of the end-users and the goals of the organization become secondary.

The difference between project and product might seem subtle at first, but it becomes quite obvious in practice. The Project Management Institute (PMI) defines a project as “a temporary endeavor undertaken to create a unique product, service, or result.” The product is the unique output of a project—the project builds the product. Many teams do not think of their solutions as a product, but the definition of product is quite broad including tangible items that can be sold in stores, as well as new software, bug fixes, process enhancements and really anything made to be used or sold (Merriam-Webster).

In practice, teams that emphasize projects:

focus on team operations
measure project phases, % complete, documents, timelines, deadlines, budgets, bugs, resources, etc.
debate how to optimize project operations
make decisions based on the team’s needs

Whereas teams that emphasize products:

focus on value
measure value delivered, end user satisfaction, speed to value, and learning
debate how to make a solution more valuable to the end users and the organization
make decisions based on end user needs and/or strategic goals of the organization

One way to reduce the emphasis on projects is to help your team rethink the Iron Triangle (aka the triple constraints of project management). The standard iron triangle usually looks something like this:

This approach assumes quality is achieved by controlling/balancing schedule, cost, and scope. If any of the constraints spiral out of control, the quality of the solution will suffer. If scope gets too big, schedule and resources (cost) must increase or the project quality will suffer. If the schedule gets too tight, the scope needs to be reduced. If the project overruns its deadlines (schedule), the cost will go up. You can’t change one, without impacting the others.

But, what if we modify the Iron Triangle to this:

Is this really different? Is it just semantics? Aren’t quality and value really the same thing? They aren’t the same! Value adds a dimension to quality—emphasizing that the quality of the solution matters only to the extent the user and organization derive value from an increase or decrease in quality. Keeping value at the center shifts everyone’s thinking away from the traditional project management approach to a product approach. Cost, scope, and schedule are only as important as the impact they have on the value delivered. I’ve found that putting value at the center of discussions about schedule, cost, and scope helps teams in 3 ways:

Teams Stay Focused on the End User

When quality defines success, it becomes possible to deliver high-quality solutions (minimal defects, no missed deadlines, no cost overruns) that no one wants or needs. That’s why usability, usefulness and/or value need to be part of the discussion.

Product value provides a strong foundation for every project. Strong teams start each project by exploring context in terms of product value and keep questioning value throughout the project lifecycle.

Teams Make Better Decisions

The value perspective helps you make better decisions throughout the project lifecycle. Teams that make decisions based purely on cost, schedule, and scope, miss out on opportunities to maximize value. It might be ok if the project goes over schedule and over budget when the team discovers additional scope that dramatically boosts value. It might be ok to miss milestones or leave parts of the project incomplete if those components do not provide value, or provide minimum value compared to the required cost and resources.

Strong teams minimize project metrics focused on operations, and create useful data that gauges cost, schedule, and scope in terms of product value to the end user and the organization. When value is already embedded in the data, value becomes the driver of decision instead of process quality. Teams stop making decisions that benefit them and begin to develop empathy for the end-users.

Teams Become More Agile

Putting value at the center of all discussions and decisions is the easiest way to bring agility to your project. The focus on product over project helps teams adapt. They embrace changes with confidence because the “why” makes so much more sense when change is discussed in terms of the end goal (user satisfaction) rather than the process. It brings relevance and context to change.

High performing product teams have a shared understanding of value that makes the need to change obvious. Teams become more adaptable and efficient as they streamline processes to focus only on what needs to be done to deliver a high-value product.

So, how do you bring value into discussions about timeline, budget, resources, documents and deadlines? Frame questions with value:

How do these metrics measure end user value?
Why is this deadline important to the end user?
How does this deadline maximize value?
Is this deadline early enough to leverage the value the solution provides to the end user?
How much are we willing to spend to provide this value?
What do we need to learn to increase the value we can deliver?
Are we spending more than the value the solution will apply?
Do these project tasks/documents provide value to the end user?
Do we have the right resources to deliver value to the end user?
What is the smallest scope needed to provide value?
Are there areas of scope that don’t provide value? Is this just enough to provide value and meet end user needs?

’m not saying that project operations, methodologies or frameworks are evil. Instead, I am encouraging you to take a look at your team and determine if you have a project prominence roadblock. Does your team emphasize project operations at the expense of product value? Your outcomes will improve dramatically if you let product value lead and smash through that project roadblock.

From the Archives: Diving Into Unofficial Roles & Responsibilities of the Business Analyst

Written by Angela Wick on August 18, 2016. Posted in Articles.

Why are we the psychologists and the babysitters?

Often on airplanes I get asked, “So, what do you do?”

I am sure if you travel you get this one as well! Do any of you answer with “I am a therapist?”

Well, I do, and it works really well! I am a therapist that helps business teams and technology teams work together and create meaningful products, services, and systems.

I help them agree on changes and create a shared understanding.
I create a process and platform to communicate.
I make them both feel like they are the ones who came up with the ideas.
I make conflict seem like a non-issue and create win/wins.
I present options and alternatives and work through, with the pros and cons.
And, they pay me an hourly rate to do this!

You rarely see “therapist” on a list of required BA skills, but a comparison of BA job descriptions across industries, across nations or even across a single organization, yields an amazing variety of responsibilities and required skill sets. Even the industry leading IIBA BABOK (embedded link: http://www.iiba.org/babok-guide.aspx) highlights more than 20 underlying competencies that support the professional practice of business analysis.

Related Article: Your Next Business Analyst Will be a Robot

Lengthy BA skill lists that include creative thinking, technical skills, adaptability, listening, solution knowledge, teaching, testing, leadership, facilitation, etc., confirm our reality that BAs are expected to be the Swiss Army Knife of the project, product, IT, or operations world. It’s no wonder that most BAs claim to “wear many different hats.”

Despite the wide variety of accepted roles and responsibilities, BAs are often asked to wear strange hats—to take on unofficial duties that don’t really fit the wide range of normal. I get asked in my classes on a regular basis: “Is it the BA’s role to ___________?” Students fill in the blank with common things like testing, coding, and project management, but hostage negotiator, spy and therapist have also landed at the end of their question!

Here are a few true stories I’ve collected over the years, with names changed to protect those who might be embarrassed by their big, floppy, gaudy, leopard-print hats:

Undercover Agent

BA Becky was a well-respected senior BA in her organization. The BACoE leader recognized her accomplishments by asking her to mentor a struggling team. The odd part of the assignment—BA Becky was asked to be an undercover mentor—she was not allowed to tell the team she was mentoring them.
BA Barry was on a project team that needed to create a pricing strategy for the organization’s products. The strategy included several assumptions about their competitor’s pricing. The team leader asked BA Barry to “secret shop” the competitor to validate the assumptions.

Ghost Writer

BA Beth asked her stakeholders from California, Texas and Arizona to travel to Minnesota for a full-day face-to-face requirements review meeting. The day before the big meeting, the project manager realized that BA Beth’s requirements were a huge mess. The requirements review would be a disaster. So, the PM asked BA Bart to stay late, re-do BA Beth’s requirements, and bring the new and improved requirements document into BA Beth’s meeting.

Translator

BA Brody was fluent in Spanish, so it makes sense that he was asked to review, translate, and validate a 6-months old, 300-page requirements document written in—Portuguese! The business sponsor asked, “Since you are fluent in Spanish it won’t be too hard to translate, right?”

Scapegoat/Peace Negotiator/Psychologist

A crafty project manager tossed BA Ben under the bus when she asked Ben to present a feasibility analysis to an erratic, f-bomb-wielding business owner. The business owner had great vision, but cost and feasibility did not meet his expectations, and the PM did not want to be in the line of fire.
BA Belinda got along well with everyone on her project team. So, naturally, the project manager asked BA Belinda to “figure out” a way to get a notoriously mean and stubborn database engineer to cooperate with the team.
Late one afternoon in mid-October, BA Betty found out she would be laid off at the end of the month. That same day, BA Bill was asked build a relationship with Betty to get the information he needed to take over Betty’s requirements work for a few projects. Obviously, laid-off BA Betty was NOT excited to do the knowledge transfer!

Babysitter

BA Brent was very smart but quite odd. His analysis work was solid, but his social skills were suspect. The team leader asked BA Betsy to help Brent stay focused, to monitor his interactions with the business SMEs and to step in when needed to ensure deadlines were met.

After Hours Snooper

BA Bill worked in a business unit where employees processed checks. Employees were required to secure the checks when they left the office each night. To validate compliance with check procedures, BA Bill was asked to stay late one night to search employee cubicles for unsecured checks.
Important documents were missing from several client files in BA Brenda’s organization. Brenda’s team leader asked her to return to the office after hours and search processing analysts’ desks for the missing documents.

Data Detective

A third-party software vendor refused to provide their data model to their customer. The customer needed the data model to develop requirements and meet the needs of their business. BA Barb, a member of the customer project team, was asked to reverse engineer the vendor data model.

What is it about the BA role that makes us prime targets for these odd assignments? I don’t see project managers or testers or developers wearing these odd hats.

The majority of these unofficial roles rely on our ability to build and maintain relationships with a wide variety of people. Maybe, these odd assignments are a compliment? Perhaps people skills are the primary strength of effective BAs, and these unofficial roles are just a side-effect of our success.

Have you ever taken on one of these odd roles or do you have another unofficial BA role to add to my list? Share your story in the comments below!

Note: This article was originally published on batimes.com on September 14, 2015

Well, I do, and it works really well! I am a therapist that helps business teams and technology teams work together and create meaningful products, services, and systems.

· I help them agree on changes and create a shared understanding.

· I create a process and platform to communicate.

· I make them both feel like they are the ones who came up with the ideas.

· I make conflict seem like a non-issue and create win/wins.

· I present options and alternatives and work through, with the pros and cons.

· And, they pay me an hourly rate to do this!

Here are a few true stories I’ve collected over the years, with names changed to protect those who might be embarrassed by their big, floppy, gaudy, leopard-print hats:

Undercover Agent

· BA Becky was a well-respected senior BA in her organization. The BACoE leader recognized her accomplishments by asking her to mentor a struggling team. The odd part of the assignment—BA Becky was asked to be an undercover mentor—she was not allowed to tell the team she was mentoring them.

· BA Barry was on a project team that needed to create a pricing strategy for the organization’s products. The strategy included several assumptions about their competitor’s pricing. The team leader asked BA Barry to “secret shop” the competitor to validate the assumptions.

Ghost Writer

· BA Beth asked her stakeholders from California, Texas and Arizona to travel to Minnesota for a full-day face-to-face requirements review meeting. The day before the big meeting, the project manager realized that BA Beth’s requirements were a huge mess. The requirements review would be a disaster. So, the PM asked BA Bart to stay late, re-do BA Beth’s requirements, and bring the new and improved requirements document into BA Beth’s meeting.

Translator

· BA Brody was fluent in Spanish, so it makes sense that he was asked to review, translate, and validate a 6-months old, 300-page requirements document written in—Portuguese! The business sponsor asked, “Since you are fluent in Spanish it won’t be too hard to translate, right?”

Scapegoat/Peace Negotiator/Psychologist

· A crafty project manager tossed BA Ben under the bus when she asked Ben to present a feasibility analysis to an erratic, f-bomb-wielding business owner. The business owner had great vision, but cost and feasibility did not meet his expectations, and the PM did not want to be in the line of fire.

· BA Belinda got along well with everyone on her project team. So, naturally, the project manager asked BA Belinda to “figure out” a way to get a notoriously mean and stubborn database engineer to cooperate with the team.

· Late one afternoon in mid-October, BA Betty found out she would be laid off at the end of the month. That same day, BA Bill was asked build a relationship with Betty to get the information he needed to take over Betty’s requirements work for a few projects. Obviously, laid-off BA Betty was NOT excited to do the knowledge transfer!

Babysitter

· BA Brent was very smart but quite odd. His analysis work was solid, but his social skills were suspect. The team leader asked BA Betsy to help Brent stay focused, to monitor his interactions with the business SMEs and to step in when needed to ensure deadlines were met.

After Hours Snooper

· BA Bill worked in a business unit where employees processed checks. Employees were required to secure the checks when they left the office each night. To validate compliance with check procedures, BA Bill was asked to stay late one night to search employee cubicles for unsecured checks.

· Important documents were missing from several client files in BA Brenda’s organization. Brenda’s team leader asked her to return to the office after hours and search processing analysts’ desks for the missing documents.

Data Detective

· A third-party software vendor refused to provide their data model to their customer. The customer needed the data model to develop requirements and meet the needs of their business. BA Barb, a member of the customer project team, was asked to reverse engineer the vendor data model.

What is it about the BA role that makes us prime targets for these odd assignments? I don’t see project managers or testers or developers wearing these odd hats.

Have you ever taken on one of these odd roles or do you have another unofficial BA role to add to my list? Share your story in the comments below!

2 Requirements Tasks You’re Probably Spending Too Much Time On

Written by Angela Wick on August 11, 2016. Posted in Articles.

Can you guess the number one question I get from requirements leaders across the world?

Whether their team is agile, traditional or hybrid, whether their team has 2 members or 250, whether they are creating cutting edge products or maintaining legacy systems, their primary concern remains the same: “How do we get requirements done FASTER?

Despite great intentions, leaders react to this time crunch pressure in a way that actually decreases the speed and quality of their requirements process. The “Get it done faster!” command tends to shift the team’s focus—discussion, collaboration, and true analysis time gets cut short and completing detailed requirements documentation (BRDs, SRSs, use cases, user stories, etc.) takes priority. I see a lot of BA teams struggling with this constant pressure between deadlines and quality.el

In this battle between quality and deadlines, many give into the deadline pressure. So, they jump to documentation without much dialog and analysis and use the document review process to elicit and analyze. You might think this makes sense, especially in well-established organizations, but it will NOT help you speed up your requirements process.

When teams minimize planning, elicitation and analysis, and spend most of their time documenting and reviewing requirements, the process will be long and painful, and teams will miss opportunities to boost value to end users.

So, how is your team doing? What’s the right mix of requirements activities to maximize speed and quality?

Make a pie. Estimate the % time you are spending on these five requirements activities: planning, eliciting, analyzing, documenting and reviewing. Does it look like this?

If your time allocation looks like this, I’m sad to report you are probably doing a great job documenting something that will cause scope changes, rework, and may even result in more problems than value; adding to the ever-growing backlog.

We need to spend less time documenting and reviewing! Documenting and reviewing are low impact forms of communication and collaboration. This means they are not meaningful to the type of thinking requirements work entails. Documenting and reviewing use parts of our cognitive processes that do not help build consensus, do not help connect the dots, and do not inspire critical thinking and progress in our solutions.

So, stakeholders leave meetings drained. Then, hours or days later, attendees think of changes and ideas outside the meeting. They dialog with others and then bring “last-minute” changes to the team. This results in a slower process overall. It takes LONGER to get the same result when teams minimize planning, elicitation, and analysis.

In requirements, we need to shift mindsets and practices to get the critical elicitation and analysis dialog and modeling completed before documenting and reviewing. This will result in quicker meetings and reviews of requirements.

A better mix for all teams (agile, traditional and hybrid) looks something like this:

Documenting and reviewing, when everything else is done right, should take less than 5-10% of total requirements time. We need to guide stakeholders through the process, a process we own as BAs. We must advocate for the importance of planning, elicitation, and analysis and share the risks of reducing or skipping these activities.

Here are a few benefits and risks you can use to help your team or your stakeholders transition to a faster and better requirements:

Requirements planning is about understanding the context, problem, goals, risks to value, and requirements approach. Even agile teams need to plan. It’s the foundation for building the right solution the right way and ensuring the requirements process is meaningful and valuable.

What happens if we reduce or skip it?

The team does not understand the WHY of the process or the problem.
The team cannot anticipate what is coming next.
Team members do not understand how their piece fits in the puzzle or how their piece impacts the rest of the pieces in the puzzle which causes rework.
We over or under engineer the solution.
Progress is chaotic and slow while team members keep circling back to try to understand the items above.
The organization will waste time and money solving the wrong problem.
Trust breaks down between teams.

Requirements elicitation is about getting stakeholders to create a shared understanding of the future state. Elicitation is an iterative process that helps stakeholders move from the big picture down to the finer details. We use models and diagrams to help stakeholders understand processes, workflow, data, user experience, rules/logic/decisions, exceptions, non-functional requirements, etc. Even seemingly straightforward enhancement requests require elicitation to determine if it’s the tip of an iceberg.

What happens if we reduce or skip it?

The team will not understand what the future state looks like, how it delivers value or how it will impact them.
The requirements will have gaps as stakeholders assume their request covers more than stated.
The team will miss innovative ways to bring value to the end users.
The organization will waste time and money fixing the solution/product after implementation.

Requirements analysis helps us understand the impacts of the future state and the people, processes, and technologies are affected. Again all teams, agile and traditional, need to use analysis activities to get the requirements right and build something useful.

What happens if we reduce or skip it?

End users will not be prepared to support or use the solution.
The team will not find requirements gaps, which will generate issues at implementation and require significant time and effort to address.
The team will not maximize the solution value. End-users will not be satisfied with the solution and will request major enhancements or simply avoid using the solution.
The organization will waste time and money building the wrong product/solution.

When planning, elicitation, and analysis are done well, documentation and review are simple and speedy.

The overall goal of planning, elicitation and analysis activities is to create a shared understanding of the various areas of scope, value, and impact. To simplify even further, we get everyone on the same page, so we don’t waste time creating and reviewing irrelevant documentation.

When we have shared understanding it’s easy and quick to put all the pieces into a user story with acceptance criteria, or a requirements document, or a tool. The review/sign-off process becomes quick as well because the team already understands context, scope, value, risk, etc.

How do you minimize time spent on documentation and review? Please share your tips in the comments below.

Feature Thinking vs Value Thinking: What’s the Difference and Who Cares Anyway?

Written by Angela Wick on July 13, 2016. Posted in Articles.

How do you start your requirements process? Many agile and traditional teams start their process by defining features. While I don’t always disagree with this approach, it’s a potentially dangerous and slippery slope if teams are not careful. The mindset or context you use to begin your requirements process has a huge impact on the time, cost, and quality of the product or solution.

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.