…is one of the most frequent flash points of conflict between business and engineering—the feature requesters and feature implementers
tldr: Feature request should start with the problem and end with the success criteria. Solution suggestions are secondary.
How it works right now
Feature requests are frequently communicated in a suggestive method.
For example:
Please build me a page where patient information is on top, their tests are in the middle, and the results are somewhere on the side.
Instead of:
The problem is users have to open multiple tabs to read patient specific information. We need to make things accessible in 1 page.
Why does this happen?
This happens because feature requesters (oftentimes the business team) don’t know better. They think suggesting a solution is the clearest way to communicate a feature. They do not realize that their own interpretation of this issue is an added layer of complexity for the engineers.
Why is it bad?
If this conversation happened between a senior business person and a junior engineer, the junior will find it hard to say no. Unclear feature requests become suboptimal code and the team incurs more technical debt.
If engineering has to reject the suggestion, business will feel shot down and hurt. Engineering will look arrogant.
If business and engineering don’t have enough time to sync, the engineering team is left to wonder what exactly the client needs. We’ll have a product like this Tree Swing.
The right way
Feature request should start with the problem and end with the success criteria. Solution suggestions are secondary.
To illustrate this point, let’s analyze a real conversation within our team.
Context
In Dashlabs, we’re designing our own case to house our machine integration hardware. We tape that case to the side of laboratory equipment it is connected to. This is our box.
Conversation example
In a brainstorming session, business made this request to engineering:
Can you guys add an attachment to the bottom so we slide it in and out when doing hardware maintenance? And so we can properly tamper-proof it? We stick the attachment to the lab machines.
The request is vague and the problem business wants to solve is unclear. The engineering team is at a lost on what to say.
Engineering responded with:
Like a mounting plate that this slots onto? We can do that, yeah. Though if we're gonna be taping on the mounting plate anyway, it might just be redundant. Cause we can just snap off the cover and remove the pi itself if we need to service it. Though I guess it would add a little more flexibility with regards to what surface you want to mount it onto.
In my opinion, it would look nicer. But not a top priority.
The engineer, unsure of what problem, had to clarify and politely reject the idea—careful not to offend sales.
Seeing that engineering did not understand, business added:
My main concern for this is really just:
1. Making sure no one can access the inside easily without us knowing
2. In case the box needs on-site repairs during a run, we won't be in the medical technologist's way
With more clarity, engineering crafts a slightly better response—but only addresses the symptom of the problem.
But to address issue 1 properly, we would require a new design for the case--one that isn't snap-fit. Or at least, I'm not really seeing how adding holder would address issue 1
Business tries to add more context.
The best we could do now is a tamper proof sticker I guess. Was thinking we could make it a screw-on cover, then we add seals to those.
Finally, with enough clarity, engineering provided a cohesive response.
This for sure is going to be a later feature. but at least for now, the priority is implementing offline logging and the graphical user interface. The case redesign to use screws and screw seals is quite complex. Plus the viability of using the case long term isn't that good because the screws eat into the plastic every time you have to open the box.
But if we ever do decide to go for a screw-on cover, we could opt to use bolts instead. We can add indents on the bottoms that the nuts could fit in
Insights
Because the feature request was communicated through solution suggestions, the conversation became a negotiation between business and engineering. Business (non-technical) throwing uninformed suggestions, while the engineering (technical) politely rejecting each one.
This gets stressful. Engineering is put in a tough spot rejecting the business’s ideas… because what can engineering do? Work on an unclear idea?
Engineering is annoyed at unclear suggestions. Business feels shot down and unimportant. We end up with an unhappy team.
A better way
Feature requests should only be communicated with the problem and success criteria. Think of how much better the conversation could have gone had business said:
Hey, I am worried about security. Can we find out if our box is tampered with?
I am also worried about presentation. Right now, we use double-sided tape to stick the box to our machines. We leave tape marks on their machines each time we open the box. Can we avoid this?
Let’s analyze this features request.
- The security problem is clear. The success criteria is knowing when a box is tampered with.
- The presentation problem is also clear. The success criteria is not leaving tape marks whenever the box is opened.
This language is clearer. It follows this format:
PROBLEM + SUCCESS CRITERIA
Problem 1:
Hey, I am worried about security.Success criteria 1:
Can we find out if our box is tampered with?Problem 2:
I am also worried about presentation. Right now, we use double-sided tape to stick our boxes to machines. We leave tape marks on their machines each time we open the box.Success criteria 2:
Can we avoid leaving physical marks?
With this structure, it is easier to evaluate the validity of this problem. It is also easier to come up with a solution. No one has to reject uninformed suggestions, and no one is shot down. Problems are solved faster this way.
Caveat
This essay so far sounds antagonistic towards business. It should not be. The converse also applies.
In topics where business is a domain expert—engineering should not impose.
For example, we’ve had tough problems with pricing. Business wants custom pricing schemes for clients—and this is important when we iterate!
Engineering was not happy because it made building a stable system harder. Engineering also made faults in communicating feature requests to sales. It also caused lots of back and forth. After much reflection, engineering’s feature request to sales became:
We don't have a clear logic for pricing. We do not know when a client can be billed for a specific service. What is the specific trigger to start billing?
Breaking it down
Problem:
We don't have a clear logic for pricing. We do not know when a client can be billed for a specific service.Success criteria:
What is the specific trigger to start billing?
In this case, business is far more qualified than engineering in pricing. The business team has domain expertise over the market—and engineering should leave space for business to exercise to their better-informed judgement.
Thanks to the Dashlabs team for helping me with edits.
