Back to blog overview

October 6, 2020

Getting to the Why

Kevin Craine



Senior Software Engineer
Nottingham, NH

Allowing development teams to build amazing solutions starts with the “Why” not the “What”. Sure there is acceptance criteria that must be met, but how do you make sure that what is getting built is what is actually needed?

The secret lies within a simple yet powerful shift in focus. Always start with a great "Why" to everything in your development cycle. I could easily say everything in your company, or for that matter, your life but let’s try to save the world one piece of software at a time.

Putting the “Why” First


The quickest way to get understanding from everyone is by emphasizing the business value. Why is the feature important? This allows for greater buy-in and flexibility. Focusing on the "Why" allows developers to make the implementation tailored to the business needs. The quality assurance team then can apply the "Why" to what they are testing, further validating and refining the business value.

Most people communicate via “What”. Which is great when communicating what needs to be done, but it can clutter the mind with what and how before getting true buy-in on the feature/idea/story.

Do a search for “user stories” and you will find article after article littered with the “Why” at the end of story. It could be argued that will make the “Why” stick with the reader. In my experience as a crusty old developer, the “Why” becomes noise. As soon as I see the "What", common thoughts tend to form: “They want to do what?” or “Oh, that’s easy, maybe half a day's work.” or “I don’t want to touch that code, I hope <insert other crusty old developer> takes that one.”

Instead, making the “Why” the first thing everyone reads is much more powerful. It allows the reader to latch onto why this feature is so important that they need to put their limited time towards it. It is like an anchor if you will, but not one that stops the ship, but one that… allows everyone to... jump on board… …aborting analogy… backing away.

Anyways, don’t take my words or lack thereof, many have already established this format as their way to work. The original submitter of this idea was Liz Keogh in her article RIP As a… I want… So that…. Also Simon Sinek gave a great TEDx talk about Start with Why, which applies to a much higher level than user stories, but is very applicable to our work.

But how do you get a great why when most people communicate via “What”?

Jump to Conclusions (The Mat)

Unless you are the one coming up with the idea, you are extracting information from someone else. More than likely they are only talking about what they want. There is a translation that needs to happen in order to get a solution that at least implements but hopefully exceeds expectations. This translation may not include the original idea based on the real “Why”.

That said, I always start with listening to all the information possible. I want a raw brain dump from those involved before I tried to determine the root problem. Jumping to conclusions and forcing a solution too early may be a horrible idea and possibly the worst you can make.

It’s a Trap


After the initial brain dump on the idea, it is time to really dive into the dark corners. The pit of despair is waiting for unsuspecting business analysts and product owners to make the slightest misstep. But how do you find these traps?

Take Me to Your Leader

After digesting the initial idea, seek out the stakeholders involved. This may be the person that gave you the original information or not. The job at this point is to find out the true root of the problem that the idea is trying to solve.

Maybe you can ask them why and they will tell you, but most of the time more digging is involved. One method is the Five Whys. This can be effective depending on the person. It can also be annoying to the person, but that may help them really have to think about their answers.

Another method that I like to use is to ask the stakeholder who will be using this solution and how. This will hopefully get the stakeholder to empathize with the user. Once we are there, I think start asking why that user group would want/need this solution.

This gives me a few points of information. First it lets me know who they think the intended user is. Second it gives me a frame of reference for their perception of the solution for that user group. Third it allows for comparison when talking with a sample from that end user group.

From this line of questioning I may draw my own “Whys”. I then validate these ideas with the stakeholders to see if there is buy-in. Coming out of the stakeholder interviews, there should be a good understanding of the why.

At this point I write some super high level stories without any acceptance criteria that focus on the business value. I include a brief what but try to leave it open ended. The what of the story may have changed from the original request depending on the information gathered. I also do not formalize these in any way. They may be written on sticky notes or in a simple text app so they do not look “official”.

Oh Experts, Experts, wherefore art thou Subject Matter Experts

With the loose stories in hand, I doff my stakeholders and seek those whose blood will be spent by these stories. But who do I talk with? I try to include everyone that will be affected by the work that is to be done. This can include these and more:

  • Developers/Architects
  • Quality Assurance
  • Trainers
  • Designers/User Experience
  • Security
  • Vendors
  • End Users (This is a very broad category)

Once the list of subject matter experts is established, I meet with each group individually. I don’t want to bog everyone down with meetings where they aren’t completely engaged. I also don’t want too much influence from other groups tainting what information can be gleaned.

I do these meetings for three reasons:

  1. Blockers: I want to make sure there aren't any major blockers/unknowns that are going to come up and if a different what/why will help get around those blockers.
  2. Buy-in: I want people to know about what might be coming. Get them thinking about it early, so they aren't blind-sided when the work comes through.
  3. Input: The more input I get the better the stories can be. You never know who may have an amazing idea. This also helps with buy-in as well, as everyone feels more involved.

During these meetings I give a high level overview of the project. For everyone but the end users, I then talk about the “Why” focused stories. I focus on the three reasons I am having these meetings, checking for blockers and getting buy-in & input.

The end users I handle differently. There are many types of end users. They could be internal people in marketing, finance, warehousing, etc. They could be external like business customers, vendors, the public, etc.

Once I am able to determine which end users to talk with, I ask similar questions to what I asked the stakeholders. What is the current problem they are facing related to this work? How does it affect them? How are they working around it? I avoid asking questions related to what they think should be done. Some of them give that information, but it doesn’t always line up with what is the best solution. I am much more focused on determining what they perceive the root issue is. I then compare this to what the stakeholders thought.

Amaze and Delight


From here I have a pretty good idea of the “Why” and business value. I then build out more official stories which usually include a rough design depending on the project. I present the stories to the Stakeholders to get buy-in. At this point I expect glorious praises or gasps of horror especially if the “What” of the stories is not expected or has changed. I focus on explaining the “Why” or business value and discuss how the “What” is best solving it.

Deal with Soul Crushing Rejection (Feedback)


If the stakeholders do not agree with the direction, I would much rather figure that out now before we are days, weeks, or even months down the road. Usually not everything is 100% spot on, so I take input and adjust.

I repeat this process of developing stories and presenting until things get accepted or until I get fired. The getting fired thing hasn’t happened yet, but I keep pushing that boundary to get to the best solutions that we can build.


Wicked smart people say “Why” is important,  RIP As a… I want… So that…, Start with Why, you should listen to them. Write stories with the “Why” first:

  • In order to...
  • As a...
  • I need...

Interrogate stakeholders and subject matter experts until they give up the “Why” of the problem/request. Create great stories based on the “Why” that enable the team to build amazing solutions that delight everyone!


Let's Chat

Are you ready to build something brilliant? We're ready to help.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
RedwoodJS Logo

for builders

Grants Pass, Oregon • September 26 - 29, 2023
View All