Why Developers Need to Understand the Business

I've had many engineers come to me asking for better specifications over the years. The specs are too vague or the design didn't account for certain states. Sometimes it's the client asking why the developer didn't "just do this." Sound familiar?

When we began taking projects at Cause of a Kind years ago, I always ran them the way every agency I'd ever worked at ran them. A designer works with the client, they come up with a design, two rounds of revisions, then it gets handed off for implementation.

Great designers will provide some type of functional spec along with their designs with a few screens outlining all of the different states. Let's assume this is the case always. You get a perfect design that the client loves and a very detailed functional spec with it.

There's an important piece here that in all my years I've only had one developer ever ask me. It was a few weeks into a project and they said, "could you take a few minutes to just explain the business this product serves?"

I was blown away, how did I just assume that by looking at the design the business case was clear? I had been with the client from the discovery right through the design phase, which allowed my mind to fill in all the blanks because of the shared context.

My knowledge of the business case influenced my interpretation of the design. Would that drop down be aggregating user entered fields or are these a fixed set of enumerable values? It's a question I didn't ask because I knew they were fixed to the business itself.

Even with great functional specs we come across these small details constantly during implementation. When timelines get tight and it's time to decide what features to cut or make simpler we have to make tradeoffs. How can good tradeoffs be made without business context?

It was clear that developers can not just come into a project at the end. That missing context has them coding with blinders on. Some developers come from entirely different worlds where the business case is not so implicit in their culture. The explanation is key to execution.

This is when I discovered the process of user story mapping. This is the part of the discovery phase where we all get together and map the various users and the actions they take in the use of the product we are building. They give us all shared understanding.

This is also a great place for stake holders, designers, and developers to come together to build a reasonable feature set. How often are we given designs that appear to be FAR beyond the scope of what is possible in a few sprints? I'd say this is the norm in agencies.

Most of the time stake holders pine over the design and add features trying to get everything into the first version. They want to SEE their final vision. Then developers are left to frantically implement or make tradeoffs during implementation.

Then the ping pong begins between the stake holders, the designers, and the developers. Nobody wants to kill features they fell in love with, nobody wants things to go over time. The foolish throw more developers at the problem. In then end we create stress and discontent.

In the end it's always this waterfall way of thinking that creates a process that causes a loss of context as we make our way down the chain. The process of discover, design, two rounds of revisions, build is so entrenched in agency work nobody questions it.

It all ends with a big reveal that leaves clients wanting, designers scratching their heads, and developers demoralized.

Instead we introduce the user story map early. We bring in representation from all sides of the build and we never ideate in a vacuum. When we begin working on features we do so with this shared understanding, this empowers developers to make better assumptions.

Through the course of a project timelines are always going to change. This is the norm. There is always MORE software to build. The key is empowering the people working on the project at every step to ask the right questions and make informed decisions.

Everyone knows that we will need to make tradeoffs, to the feature set, to the design, to the code itself. What we want is to make tradeoffs we can collectively agree make sense given the problem we are all here to solve.