When Visual Models are Better than Textual Requirements (Part II: Relationship Maps)

In this series that starts with Part I (State Diagrams), and ends with Part III (User flow diagrams), I show how different visual models can help you create better requirements. If you don’t want to miss the next installments, make sure to follow me on LinkedIn or subscribe to our infrequent updates entering your email to the right.

# # #

As a business analyst working on software projects, you’re probably asked to draw a lot of diagrams. Sometimes it may be hard to understand why, when textual requirements is what’s traditionally required to get “sign off” from stakeholders for what needs to be built. But as we started to see in Part I: State Diagrams, visual representations can help you understand what questions to ask to uncover potentially hidden requirements, reconcile differing viewpoints about what the system is meant to do, and communicate the big picture of a solution being built incrementally, among other benefits.

In this article of the series, we’re going to take a look at relationship maps. While state diagrams focus on a single business object and how it transitions states in response to conditions and events, and process maps depicts the sequence of steps that transform inputs into outputs, a relationship map highlights the inputs received from external parties (customers, providers, partners) and the outputs provided to them, as well as the functional areas involved in handling those inputs and outputs and the handoffs (inputs and outputs) within the organization.

Imagine that you’re starting to work on a system to automate invoice processing for a hardware repair company. A relationship map for the project could look like this:

Because the diagram focuses on the affected business functions and their inputs and outputs, it’s easy to determine the cross-functional relationships between these functions (engineering, account management, finance) and the external actors (customers and providers). After building this map, a BA could identify a potential process improvement opportunity in the handoff of invoices to the customers (highlighted in orange above).

The analyst could ask relevant questions to stakeholders, such as, “Given that the finance department is responsible for generating the repair invoice the customer gets and receiving the payment, does it still make sense to have the handoff of the repair invoice from finance to account management before it reaches the customer?”  The proposed change would be captured in a relationship diagram like this:

But now, comparing it with the previous version, it’s easy for the BA to see that the account management is left “out of the loop” regarding the completion of a repair order, previously signaled to them via the customer invoice forwarded by the finance team. We can then modify the diagram again, to make sure the notification still happens (see added green arrow):

Note how in this version the customer still has to submit a repair request to the account management team, responsible for validating the terms, such as the service level agreement the request has to adhere to. But account management no longer needs to be involved in the customer invoicing process: the finance team can invoice the customer directly. However, since in the “as-is” process the invoice received from finance served as the notification to the account management team that the service had been provided, we now need to extend the “repair complete” notification issued by the engineering team to the finance department (for invoicing purposes) so it also reaches the account management (new green arrow).

Showing the first and last diagrams (as-is and to-be ) above to business stakeholders makes it much easier for them to understand the recommendation for the process change compared to writing a textual description of the proposed changes and directly asking for sign off for the final requirements. Once the process change has been well-understood and approved, a textual requirement can be created to communicate to the development team what needs to be built and tested:

When the engineering team marks a repair service as complete, a “repair complete” notification will be forwarded to:

a) the finance system (existing behavior, which already triggers the invoicing process); and

b) the account management system (new functionality that will update the order status in the account management system so that account managers can have the information readily available when interacting with customers over the phone).

# # #

Visual representations of business functions involved in a business process, like the one provided by relationship maps, can be extremely useful for identifying areas of improvement and communicating proposed changes in existing processes. Relationship maps offer an excellent view of the key business entities and the inputs and outputs that flow between them. They can also serve as input for the creation of other useful diagrams such as a process map, with the functional areas becoming lanes in the diagram. By not focusing exclusively in one type of visual representation of the business model, BAs can dramatically reduce the risk of overlooked requirements or missed opportunities to improve business processes.

# # #

Looking to take your textual requirements and visual models to the next level? Join the waiting list for the coaching program Crafting Better Requirements.


The difference between an average and a high-performing business analyst

When asked to describe their role, many business analysts working on customer-facing software products or internal information systems use terms like “liaison”, “bridge”, “communication line”, and “translator”, typically referring to work they do to make sure “what the business has in mind for a computerized system is accurately understood by the technical team”.

This interpretation of the BA job is very limiting. It comes with an implied assumption that someone on the business side has done the proper analysis of the business problem, and the job of the BA is limited to finding a common language and ensuring the objectives between the two groups are aligned so that the need communicated by the business can be fulfilled by the IT or software engineering team.

Every time I started a position involving business analysis, I took a different approach, making my #1 job not develop requirements that translated the business and user needs into a technical solution, but to make sure all software solutions I worked on had a clear business motivation in sync with the business strategy.

This shift in perspective can quickly take you from a reactive to a more proactive position in your organization. Here’s an example to illustrate the difference:

Jim, the average BA

Tom, the business stakeholder: “Hi, Jim! We just received a report from the customer success team showing that we have a large number of customers complaning about the latency of the Orders Placed page. It’s imperative that we fix this issue so we can increase customer satisfaction. Can you make sure the IT team makes the Orders Placed page run faster?”

Jim, the average BA: “Sure, Tom! Let me get right to work.”

Jim goes talk to the development team, discovers that the Orders Placed page takes between 8 and 12 seconds to download, and that with some significant work, can have its latency reduced to 4-6 second. He then writes the requirement:

“The Orders page shall download completely within 6 seconds over a 20 Mbps or faster Internet connection.”

Tom signs off on the requirement, and the work is handed to the development and testing teams. Two months later, the change goes live, but with little impact to the business in terms of customer satisfaction or retention. What went wrong?

Jane, the high-performng BA

Tom, the business stakeholder: “Hi, Jane! We just received a report from the customer success team showing that we have a large number of customers complaining about the latency of the Orders Placed page. It’s imperative that we fix this issue so we can increase customer satisfaction. Can you make sure the IT team makes the Orders Placed page run faster?”

Jane, the high-performing BA: “Sure, Tom! Can I look for a 15-min slot on your calendar for us to go over your findings and make sure I have all the information I need to proceed?”

Tom, the business stakeholder: “That works, thanks!”.

Jane talks to Tom to gather more information. She also schedules some time with the head of the customer success team and the system’s tech lead to better understand the context of the complaints received, and learns the following:

  • Only customers using the old version of the application are complaining that the Orders Placed page is too slow.
  • The latency of the Orders Placed page has not changed between the old and the new version. What changed was simply that the new version uses incremental rendering to start displaying content as it becomes available, rather than waiting to display the complete page only after it’s fully downloaded. Even though in the new version the customer still has to wait until the page is entirely downloaded in order to interact with it and get the information they need, the perception of slowness is no longer there.
  • The customers in the old version are legacy customers who aren’t considered “ideal customers” for the business. Their lack of commitment to upgrade to the new version is just one more sign they’re not extracting enough value from the relationship to remain customers in the long run.
  • The current focus of the business is to increase satisfaction and retention rates among its  group of “ideal customers”, who are already in the new version and happy with the performance of the Orders Placed page.
  • The chief complaint within the “ideal customers” group is not that the Orders Placed is too slow, but rather that the information offered about the estimated delivery time is often wrong.

Armed with all this information, Jane can go back to Tom with a better diagnosis of the problem.

Jane, the high-performing BA: “Tom. looks like making the Orders Placed page run faster is not going to help you achieve your business objectives. Here’s what I learned [ summarizes the key points from her investigation ], and here’s how I recommend we proceed…”.

Jane can now work with Tom on a plan to increase the accuracy of the estimated delivery time. Any changes that are required in the system to achieve this objective (e.g., querying the shipping carriers more often, refreshing the EDT more often) can be tackled by the developers who would otherwise be busy making the page load faster with little to no impact to the desired business outcomes.

# # #

When a BA is doing only reactive work, he or she is more likely to have people questioning the need for the role. After all, why can’t Tom the business stakeholder go directly talk to Jeff the developer about “making the Orders Placed page faster”?

The more proactive your work becomes, the less risk you face of your job being considered superfluous. A business analyst can deliver incredible value to an organization by going beyond understanding and translating the wants and desires of the business stakeholders to technical stakeholders. High-performing BAs also avoid the risk unnecessary scope creep that reactive BAs constantly face. You’ll know you’ve become a high-performing BA when you’re helping the business answer two fundamental questions before getting into “solution mode”:

  • What is the real problem to be solved here?
  • Is this problem even worth solving?


# # #

Interested in getting better at problem definition?

Register to our free email course “Understanding the problem: A key step to being a successful problem-solver” using this form.

How do you know when a feature customers are asking for is worth building?

One thing I like about digital products is that this kind of product is never finished. Not only they can continue to change over time, change is often critical to keep the product relevant in the market as technology and expectations evolve. For example, a web-based ride sharing application requiring people to plan their ride one day in advance could be extremely popular before the arrival of smartphones, and quickly become irrelevant once it’s possible to open a mobile app and send a request for a ride that a driver nearby can instantly accept.

Yet, something I hear often from startup founders in the digital product space is how uncertain and “gut feeling based” their process to decide what to build next is. And even founders of highly successful startups who are still in charge of product decisions, when interviewed by podcasters interested in learning their secrets to growth, typically describe their decision-making process as something imprecise and opinion-based rather than systematic and evidence-based.

The problem here is that, when you don’t have a solid framework to answer the question, What is the next most important thing to spend engineering time on?, sooner or later you’ll end up falling into one of these traps:

  • Ignoring customer input and building an idea the CEO fell in love with that turns out nobody is interested in using or paying for.
  • Meeting customer requests to the letter and ending up with a “me-too” product, or a bloated product that frustrates users, or a new feature that customers said they would love but now renders their well-established workflows useless.
  • Listening to recommendations of “power users” or “early adopters” and creating a product of limited appeal to your larger audience.

In a recent article for LinkedIn, I gave an example of a time when I almost fell into the trap of listening too closely to customer input (being saved by Eric Sylvia, a colleague from the customer success team who knew better than accepting at face value the feedback received from multiple customers):

I was working as a product manager for a software product that was receiving a significant amount of complaints about response time. Users would often write to customer support to express their dissatisfaction with the time that a page took to finish loading the first time after they opened the application. Some users would also point out that one of our main competitors (which offered the same capability in a free version of their product, making it relatively easy for them to compare) had a much faster load time.

As a product manager with a technical background, my first reaction was to go talk to the engineers to better understand the constraints to make the page load faster. Not Eric! Despite also having a technical background, he didn’t take anything for granted. Eric went through the trouble of setting up the exact same scenario in both our product and the free version of the competitor’s, and timed how long it took for each page to load.

Turns out that our product loaded faster. Upon further investigation, it became clear that our software created the perception of being slower to load because of an animated loading icon that was kept in display while the system retrieved the content. The competitor’s product simply showed the static elements of the page, with a blank space where the content was being loaded. This is a fantastic example of sweating the right small stuff. Before jumping to the idea of making the page faster, this colleague decided to check whether we had identified the right problem to solve–which in fact we hadn’t. In reality, instead of requiring a high-cost, high-effort solution to try and reduce latency on a page that had already been optimized for performance, the solution was trivial: just remove the loading icon to eliminate the perception of slowness.

Anthony Ulwick, in his article for HBR called Turn Customer Input into Innovation, offers another illustrative example of the threats facing companies who don’t know how to interpret customer feedback. His example is of a physical product, but the consequences are equally seen in digital products:

There are several concrete dangers of listening to customers too closely. One of these is the tendency to make incremental, rather than bold, improvements that leave the field open for competitors. Kawasaki learned this lesson when it introduced its Jet Ski. At the time, the company dominated the market for recreational watercraft. When it asked users what could be done to improve the Jet Ski’s ride, customers requested extra padding on the vehicle’s sides to make the standing position more comfortable. It never occurred to them to request a seated watercraft. The company focused on giving customers what they asked for, while other manufacturers began to develop seated models that since have bumped Kawasaki—famed for its motorcycles, which are never ridden standing—from its leading market position.

This type of disappointment can be easily avoided if you use an approach like the one I described in this other article: When customers ask for a feature or product enhancements, instead of taking their requests at face value, ask them to explain the context in which they realized they needed the feature, and what is is that they will be able to do when they get their request that they can’t do now.

I don’t know what answers Kawasaki would have gotten from asking these questions to customers asking for extra padding on the sides, but from their initial request I can imagine that the “job” customers were hiring the jetski to perform wasn’t a challenging and rewarding workout (which would be well-served by a standing watercraft), but probably something like touring and taking people for a ride. After understanding the problem space (“I want a more comfortable ride”) it would be easier to form a robust problem-space definition and then evaluate the candidate solutions (extra padding, seated model, etc.) based on their feasibility, cost, and ability to deliver value.

There are different frameworks that you can use to avoid wasting time, money and limited resources on product ideas that turn out not to be valued by customers. The ones that I’ve seen work best focus on getting answers for the following questions:

  • Who am I trying to serve?
  • What set of underserved needs from my target customers do I aspire to meet with my product?
  • What criteria do my target customers use to judge how well their needs and expectations are being met?
  • What potential solutions–obvious and non-obvious(*)–exist to meet my customer needs and preferences?
  • How will my product be better than the others in the market? What unique value will it deliver?

(*) Non-obvious solutions like “removing the loading icon” that a customer would be unlikely to come up with on their own but you can invent after asking customers probing questions to illuminate the problem space.

When your product prioritization process is based on these kinds of questions, it’s much easier to avoid the common traps listed at the top. Instead of talking about features, you’ll be articulating customer needs and desired outcomes. Instead of wondering if a product idea will “fly”, you’ll be describing the value to be delivered to the customer, and objectively measuring the candidate solutions against the benefits they are capable of providing.

It also helps to reframe the question from What should we build next? to What is the next most important thing to spend engineering time on? Sometimes the best opportunity lies not on building a shiny new feature, but on improving response time, or removing unnecessary features that are cluttering the user experience, or redesigning a user flow to make tasks easier to complete. It bears repeating what I wrote in the article Stop Prioritizing Features:

The fixation on productivity and feature throughput is as likely to lead to “bloatware”, customer aggravation, and quickly losing relevance in the market, as to produce the expected growth.


Photo credit: Vimal Kumar (Creative Commons)

Get infrequent updates from us


How to stop non-BAs from taking over the requirements work?


Photo Credit: Marcello Maria Perongini

A reader asks:

In my organization, it’s common for a business or technical person to take over the requirements documentation task for an internal system without involving one of the business analysts. This is clearly causing quality issues with the final solution, employees frustrated with systems that don’t let them to their work efficiently, etc. I’ve tried talking to my boss about it, but even though he seems to agree with my position, the issue has not been addressed yet. What else can I do to get people to see the importance of having a trained business analysts assigned to each of our software projects?

Some professions, like visual design and business analysis, are plagued by untrained people thinking “What’s the big deal — I could do that myself!”. And the negative consequences are not always apparent to everyone, like underperformance costs, internal systems that are too painful to use, and so forth. But there are definitely things you can do to try to improve the situation.

Here are a few suggestions:

1. Prepare your case. Figure out how to articulate, in layman’s terms, exactly what the problem is when business or technical stakeholders create and document the requirements themselves without the involvement of a trained business analyst capable of going through a more structured requirements discovery process. It may be completely obvious to you why that’s bad, but it’s clearly not obvious to your stakeholders. Find ways to explains the problem in terms people will understand.

2. Identify allies. Once you have an ironclad case as to the importance of BA involvement in software requirements definition, start looking around for colleagues and business leaders who could become supporters. You’re more likely to succeed if you can make it look like the change has been their brilliant idea from the get go. Let them take the spotlight and “sell” the suggestion to the rest of the organization.

3. Find the middle groundRecognize that sometimes it’s legitimate for someone from the business or technical team to write requirements for a minor project. If the BA team is small, unable to get to a simple, lower-priority enhancement project until next month when the business unit needs it sooner, it’s not always bad to have someone who is not a trained business analyst take care of the requirements.

4. When the situation is unavoidable, mitigate its impact. When it’s not possible to prevent non-BAs to do the requirements work, you might be able to mitigate some of the negative impact by providing templates, examples of what good requirements look like, and DOs and DON’Ts (e.g., instructions on how to group user stories or requirements around higher level problems or goals that logically fit together, write requirements in an acceptable way rather than using technical descriptions of how to deliver or build, etc.).  That’s not perfect, but at least if the teams are working from your instructions, their requirements documents are likely to be better than if they start from scratch. You can also enlist the development team to help disseminate best practices and reach out to the BA team for help when they realize they don’t have high-quality requirements to work from.

5. Speak up when you see the issue happening. When you discover a bad rogue requirements document, bring it to your manager’s attention. Let’s say you realize that the requirements written by a financial analyst are in bad shape. Go to your manager and say, “I’ve noticed that the requirements the financial department has written for enhancing their reporting tool are likely to create issues because they didn’t address some important non-functional requirements needed to keep the solution’s response time at acceptable levels. I wonder if there’s a way to ensure one of the business analysts on our team is always involved in this type of initiative that goes beyond minor improvements, to make sure no important requirement is missing for the development work to begin.”

# # #

The one thing that you can do today

As with any organizational change initiative, in order to things done the most important thing is finding allies for your cause (#2). Make an effort at finding, developing and nurturing allies across the organization–and not just people in positions of power.  Develop relationships with these supporters, and remember: allies need to be constantly reminded of how critical their support is. Nurturing your base of allies will dramatically increase your odds of success.

Read also: Follow-up based on readers’ questions and comments 

Acknowledgement: Tom Peters is to be credited for the idea of finding and nurturing allies as one of the most powerful means to create organizational change.
 * * * * *

More from BealProjects.com

Working for or building a startup?

3 big mistakes startup founders make

Interested in becoming the person that your organization wants in a bigger role?

If you have a few years of experience as a BA and are thinking of moving into a lead BA or BA manager position, you can accelerate that process with deliberate learning and practice from the Business Analysis Leadership group.

Smart companies will pay for it if you ask. After all, it’s a high-return investment in the very people who do the work. Not-so-smart companies need to pay attention to Adriana’s advice in this article: CIO: When was the last time you recognized and rewarded your best leaders?

Use this simple trick to become a better stakeholder interviewer


In order to excel in their role, business analysts need to be clear on the business goals their project is meant to support, and how success is going to be measured. Yet, oftentimes stakeholders get impatient to kick off a project without first clarifying the strategic direction. The typical consequence is poor requirements definition and waste of time and money building the wrong solution.

The ability to ask the right questions to the right people is a critical competency for any business analyst. The right question asked at the right time can help you get to the bottom of why a solution is needed, what benefits it will bring compared to a different approach, and any potential issues that if left unchecked would create a project roadblock.

There is a simple trick that can drastically improve the type of results you get when you’re trying to elicit information from stakeholders for a software project:

Separate what you need to learn from the questions you ask, and try to get your stakeholder into “storytelling” mode to get to the bottom of the business need.

Let’s say you’ve been assigned to a project that has nebulous objectives. Your first reaction might be to ask your stakeholders, “what are the objectives for this project?”, or “what are the desired outcomes?”. But in reality, it’s likely that your busy stakeholders didn’t spend a lot of time trying to articulate in a few sentences what they are trying to achieve. They’ll be inclined to describe the solution (“the objective is to build an executive dashboard that lets executives monitor our KPIs”) rather than present a well-articulated justification for the project that is clearly defined and aligned with overall business goals.

In order to get better answers for your questions, instead of asking directly, “what is the business motivation for this project?” or, “what business problem are we trying to solve?”, focus on getting your stakeholders to tell you their stories. Here are some examples ofquestions you can use to get your stakeholders into “storytelling mode”:

“OK, let’s imagine the future. Let’s assume for a minute that our solution is live, and let’s talk about a day in the life of someone who uses it.  What will they be able to do then that they can’t do now?

What challenges are you facing that made you decide to build this capability?”

“What happens if we don’t build this solution?”

Notice how this type of question helps your audience take a step back from discussing the solution (e.g., “build an executive dashboard”) to focus on the specific people who will use the solution, and what they’re trying to accomplish  (e.g., “quickly identify performance anomalies without having to wade through lengthy reports”).

Here’s another example. Imagine you’re documenting the process for employees of a company to submit requests for IT purchases (printers, laptops, monitors). You’re trying to figure out what needs to happen before an employee is notified that one of their requests has been denied. In books teaching people how to document a business process, you’ll find advice to ask something like, “what should already have been produced before an employee is notified that his request has been denied?”. That’s a perfectly valid way of stating your question for the purpose of understanding what you need to learn. But it’s not the best way to present the question for your stakeholders, who most likely aren’t trained to think in terms of process models that transform inputs into outputs.

You can reword the question into a narrative to stimulate your stakeholders to get into “storytelling mode” and give you the information you need without getting lost in the details of business process modeling:

“We talked about how an employee request for new equipment can be denied for various reasons: the company is changing providers and want employees to only use a different brand, the department the employee belongs to has exhausted their budget for the quarter, etc. Let’s look at a specific scenario. Imagine that Mary from the Marketing Department submitted a request for a new monitor right before the vendor she selected is removed from the approved list. Can you tell me what, exactly, would happen with Mary’s request at this point?”

By avoiding process modeling jargon (“what should already have been produced before this step happens?”) and framing your question using storytelling, you’re making it easier for the stakeholder to connect the dots from what you’re asking to what they know happens in real life. Instead of having to think in generic terms about the process steps that happen prior to the output “employee notification”, he can think in terms of a real situation to explain the process.

The interviewee could answer your question with something like, “Well, Mary would be automatically notified that her request was denied as soon as the vendor is removed from the list. The ‘request denied’ notification would include instructions on how to resubmit the request after choosing a different brand or model of equipment that’s still in the catalog.” You could then continue probing through storytelling until you had all necessary pieces of information to understand the solution requirements.

When you need to ask a question to clarify a business process or system requirement, remember to make things easier for your subject matter expert, not for yourself. That means never asking jargon-laden questions such as, “What are all the steps an item must go through to achieve the outcome of the workflow?”. Take the time to frame your questions in a way that starts a conversation and gets your stakeholders in the mood to tell you their stories about who the solution is for, what they do now, and how things will change for them later. This is guaranteed to get you much closer to finding the answers you need to specify a winning solution.


Interested in learning more? Tested Stakeholder Interviewing Methods offers a straightforward blueprint for you to get to the bottom of the real business need and demonstrate you value as a business analyst with better requirements.

Stop prioritizing features

By Adriana Beal

What do you think of our process to prioritize new features?

Whenever I hear this question, my first thought is that I don’t even need to look at the process to conclude that it is wrong.


Whether you are working on a small custom software application, or a product sold to millions of customers, your primary focus should never be new features, but rather value creation

We all understand where this obsession with feature prioritization comes from. Managers get nervous when product owners are not writing new requirements and developers are not producing more code. There’s always a pressure to “come up with themes for the next release”, “deliver more user stories per sprint”, and so forth.

Sadly, the fixation on productivity and feature throughput is as likely to lead to  “bloatware”, customer aggravation, and quickly losing relevance in the market, as to produce the expected growth.

The way to avoid this trap is to shift the focus away from feature prioritization and toward desired business outcomes.

What are the top business priorities for your company?

As Richard Rumelt writes in Bad Strategy, Good Strategy,

A leader’s most important responsibility is identifying the biggest challenges to forward progress and devising a coherent approach to overcoming them.

In practice, it’s common for leaders to fail to acknowledge the most important challenges facing the business. They ignore the power of choice, trying to accommodate all types of conflicting demands and interests across the organization.

But good product owners and business analysts demand more from those who lead. They’ll insist on gaining a clearer picture of what fundamental problems the company is trying to address, and will not rest until there’s an agreement on a focused and coordinated set of actions to tackle those problems.

How do these business priorities affect the priorities of the product or project you’re currently working on?

Let’s say you are a product manager in charge of the requirements for the next release of a SaaS (software-as-a-service) application that is offered by your company in a subscription model. And the high stakes challenge facing the business is customer churn: the company is being able to attract a large number of customers to try the software every week, but the majority of them cancel the subscription a few days after registration.

Now, instead of immediately starting to brainstorm new features that could be added to encourage customers to stick around after trying the software, you would dedicate time to understanding the root cause of the problem. You might learn from support tickets and feedback from former customers, that the main reason for customer churn is how difficult the product is to learn and how long it takes to set up.

Armed with this information, you’d be able to prioritize things like user interface redesign and improvements to the onboarding process as the most critical actions to support the goal of reducing customer churn.

Or, imagine you’re a business analyst in charge of an internal application that helps the sales team manage the sales pipeline. And the biggest challenge the sales team is facing is time wasted with unqualified leads, which is slowing sales down. Upon investigation, you may identify the scoring method used to predict the lead’s “likelihood to close” as the top obstacle to qualified leads, and prioritize enhancements to the scoring algorithm to support the goal of making the sales organization more efficient.

Note that in both examples, the deliverables that most contribute to the desired outcomes have nothing to do with building new features. In the first scenario, improvements in usability and the onboarding process could be the best alternatives to reduce customer churn. In the second scenario, improving the lead scoring algorithm might provide the highest impact in helping the sales team spend time only on the leads that are the most sales-ready.

These examples highlight the biggest problem with feature prioritization models: they start from the faulty assumption that the solution to business challenges must reside on new features, when the best opportunities for improvement may be found elsewhere. When you start from the question of where the best opportunities lie, new features become one of many alternatives to achieve the business goals. They’ll be rightfully competing with bug fixes, performance enhancements, process improvement activities, user interface redesign, marketing efforts, and many other actions capable of delivering business outcomes.

An effective prioritization process doesn’t revolve around features and release scope. It starts from shedding light into business goals and advance toward a commitment on the outcomes the team plans to support, before arriving on software features it plans to implement.


Thoughts or comments? Share them on LinkedIn

Photo Credit: Kelly McCarthy

Get infrequent updates from us


Increase the success rate of your software projects by changing your reward system

By Adriana Beal – Jan 2015

Imagine pouring money into building a new software feature or buying a new tool, only to see it ignored by the intended audience. A few recent examples I’ve witnessed:

  • A powerful project management tool chosen by executives based on its ability to provide aggregated project data to help manage overall priorities was quickly abandoned when project managers found the application hard to use.
  • A new mobile app designed to solve a real problem failed to attract buyers.
  • Changes in how a software-as-a-service solution behaved and looked, made to improve the user experience, triggered angry reactions from customers who were happy with the status quo and demanded a rollback.

idea-screening Situations like these are more common than organizations like to admit. Even devotees of agile methods often suffer from the problem, patting themselves on the back when a new release is delivered on time, on budget and with the planned quality, only to realize that they’ve committed the biggest waste of all: building software that the intended audience refuse to use.

After spending 15 years as a consultant helping organizations of all sizes build better software, I’ve come to the conclusion that the easiest way to eliminate this problem is to change the reward system.

We all know that human beings adjust behavior based on the metrics they’re held against. If your company only rewards people who come up with new ideas, or ship software on time, can you trust they will do the right thing, and seek disconfirming information before starting a new project?  For a better success rate, it’s crucial to reward also the people willing to do the hard work that doesn’t come with any guarantees, and doesn’t necessarily ship anything, but offer the highest return on investment:

  • identify solutions that are truly appreciated as value by the people who will use them;
  • analyze the merit of proposed ideas, and reject the ones that can’t produce real value;
  • refuse to add new features to a product just because a competitor has them, and work instead on the aspects that can make a product remarkable, even if it means making it easier to use, or its advanced features easier to access, without adding a single feature.

Currently, not enough of the software process is devoted to understanding the customer/user context and the causalities that drive user adoption. What Peter Drucker used to say remains 100% true: it is foolish for a seller to spend money, time, and effort developing quality as he sees it, for the buyer may not see it that way at all.

If more companies start to reward the behavior that leads to saying no to ideas that don’t match the customer’s definition of value, we should finally start seeing more software projects producing the change the business is seeking.