You may remember learning the 5 Ws: Who, What, Where, When and Why, way back in Kindergarten. Today I want to talk about the 5 Ws for Developers and how they will transform you from a developer that is told what features to build, to one that is asked, how features should be built.
- Who am I building this feature for?
- What is this feature is supposed to accomplish?
- Where will I see impact if the feature is a success?
- When will I see the impact?
- Why build this feature now?
These questions overlap and build upon each other to give you the full context around a request. Ask these questions for every new feature you get assigned. Especially if you think you know the answer!
Who am I building this feature for?
Does it interface with humans or other computers?
Is it for internal or client use?
Which clients?
The answers to these questions will tell you a lot about performance requirements, whether things should be synchronous or asynchronous, and even if you need to build a UI.
What is this feature supposed to accomplish?
This is probably the most omitted piece of data in feature requests.
I have seen countless stories that boil down to “Build a CRUD app to collect and maintain this set of data” without any context about what the data is supposed to accomplish. Which has resulted in countless followup stories to “Add these missing data points to the CRUD app”, because the original ask couldn’t accomplish the goal.
As a developer you are responsible for making sure the code accomplishes the goal. If you don’t know what you’re trying to achieve, you’re going to end up rewriting the feature. Repeatedly.
Where will I see the impact of the feature?
There are 2 goals for this question: ensure that everyone has agreed upon what success looks like, and ensure that you write your code to make tracking success easy.
If you get pushback to the tune of “the impact can’t be measured”, that is a sign that the asker is just a note taker and doesn’t understand. Most features are to get who to do more what. If you can’t find where that will manifest, then the feature request is broken
When will I see the impact?
Performance and efficiency features should have instantaneous impact. Improvements in a sales pipeline could take 6 months to manifest. Know when you should start seeing movement, and try to find ways to make it as early as possible.
Why build this feature now?
For developers, there is always more work than time. You need to know why this feature’s time is now.
Is there an upcoming regulatory change?
Is the current performance causing your clients pain?
Maybe the system is overloaded and you need it to scale?
Will the new feature bring in a new client or keep one from leaving?
How these questions tie together
When you know the answers to the 5 Ws, a magical thing happens.
You will see how to deliver a feature that achieves What for Who earlier for less effort. Most of the time you’ll never end up implementing the original feature, and soon people will start asking you how to implement the feature instead of telling you!
