Ambiguous Business Requirements

Some time ago, while working in my first job building web software, my company was seeking another developer to add to the team. As colleagues and I reviewed the job description for our hiring team, we chuckled over some of the phrasing used. In particular, one bullet point has always stuck out in my mind. It was something to the effect of:

The ability to take ambiguous business requirements and distill them into valuable software

I am paraphrasing, but that was the gist of it. You take requirements that are general, nebulous, etc. and turn them into a quality product. “This is ridiculous,” we said. “What an unreasonable expectation! How can someone produce something good if they don’t even know what they are supposed to produce?” These were some of the general sentiments expressed.

Reflecting back on this several years later, I no longer find it funny or unrealistic. In fact, I now think a quality like this is a game changer for a developer and their team.

Now, I am absolutely a proponent of intentional and deliberate communication. It is something that is crucial on healthy teams. People need to know what you expect of them, certainly. It is hard work that is worth doing. When you’re working for a startup, though, where things are moving quickly and constantly changing, it’s just not always a reality. When you’re working for a large team, with a wide array of communication points, there will be gaps.

So, ambiguity may not be ideal, but it is inevitable. As a developer, if I am presented with a task that is a bit more conceptual, I can look at it one of two ways: a) this is a burden, or b) this is an opportunity.

The opportunity presented by ambiguity

Here’s an example from my own experience. In my last two companies, we have not had a full-time UI/UX designer. In both places I have fought hard to morph our process of defining requirements from “it should do x, by moving y and toggling z” to simply “it should do x, you figure out how, then we’ll provide feedback”. Here’s why. As the developer, I have the most intimate knowledge of the technical restraints, which come fully into focus as I actually try and implement a requirement. I often would not be able to recall these restraints if I was simply reviewing a wireframe or some other type of implementation instructions before I got into the weeds of the software. Thus, our team can either:

• have business team decide requirements and suggest an implementation
• discuss it with the dev team, tweak implementation based on perceived limitations
• developer implements, learns of even more limitations
• goes back to business team, tweak implementation again
• developer completes implementation
• review implementation and make more tweaks

or we can:

• have business team decide requirements
• developer implements his/herself, bearing in mind technical limitations
• business team review implementation and make more tweaks

In the interest of time and the fact that I hate meetings, you can see why I much prefer the second option. This strategy works out well for us in most cases. I think I’ll dedicate an entire blog post to it soon.

Get to the point

Okay, sorry. So the point is. Most of the time I don’t have a lot of clarity about how to implement a feature into our existing UI before I actually start coding. As a result, it’s been up to me to learn UI/UX, to figure out how to most seamlessly introduce a feature into an existing UI without tripping up the user, to come up with creative solutions to complex problems. Up to me to maintain consistency across our suite of applications and to rely on existing patterns and seek them out when I get a new requirement. I am now not only a front end developer, but a UI/UX pro. I’ve grown as a result of being stretched.

Working at a startup or on a small team will most certainly push you, but I can see the same being true on large teams. When we receive a task and say, “I don’t know how to do this”, we should delight and not dread. It will force us out of our comfort zone, but this is how we get better. Be like Jimmy.

Clearing things up

Ironically, one of the best ways to take ambiguous business requirements and turn them into quality software is by pushing back on them and clearing up any misunderstandings. This is an important skill to balance and perceive when something is intentionally vague and when someone simply miscommunicated (or you’ve misinterpreted). And it’s so valuable to your team and leadership. People should try, but they can’t be expected to communicate perfectly every time.

For instance, on my team, not only am I lead front-end developer, but I also play a role as de facto project manager for the other developers, working with the business team to scope out sprints and issue tickets to other team members. Often, when making these tickets, I’m not aware of how much context I need to provide for a requirement (you don’t know what you don’t know). I’m also usually rushed during this process (I don’t love doing it, but it’s part of the job). Mistakes happen. It’s helpful to me when someone sees a ticket and says, “uhhhh, what now?“. It also forces me to question any assumptions I made when describing a requirement or suggested implementation to another developer. Both key pieces to building quality software.

How we handle ambiguous business requirements sets us apart as developers, employees, and co-workers. There may be days when we want to just come in to work and hack away on clearly defined tickets, but how we handle the imperfect says more about us and our potential.