The Importance of Mentioning the Business Justification in Each Design

I recently came across several examples of requirements design documents which focused on the solution and assumed we’re all aligned around the business justification. This is mostly common when all of us are already working on some project and there is a tendency of group thinking.

I personally got to make this mistake a few times.

But then I realized it will be a best practice to start off each design document with describing:

1. What is it we’re trying to solve – and it’s important not to jump to the point of why we’re trying to solve it the way we are

2. How are we going to measure it

Let’s take the common example of the space pen. During the work on the US space program, a need came for an anti gravity pen that will allow astronauts to write in space. A lot of investment was done till the result was actually achieved. In contrary, the Russian has decided to use pencils. Did the Russians solved the same problem? Probably yes.

The conclusion – understand what you’re trying to solve. You’ll probably be able to find out some other ideas on how to reach it with much less investment or you’ll be much more convincing in why the current approach is the right approach.

Great tip – follow the ‘5 Whys’ principle; once you have in mind a problem statement, keep on asking why. Sometimes, you’ll find the problem statement actually lies in a different area.

I had such a case recently when we spoke about end of life of a system. The existing system was a true legacy system and we focused at first on how to replace its functionality. Since I was relatively new to this system, at one point I started taking it a step further and started asking why do our users need to access this system in the first place. All of a sudden we realized there is a completely new solution space that didn’t involve any replacement for this system and instead we could just create an automatic back end process that will increase our efficiency.

Metrics – Once you have the right definition of what you’re trying to solve, focus on the metrics as well.

Metrics are a great way of making everybody in the solution eco system aligned around the same cause. If the metric goes down, everybody needs to think about what could have caused it and straighten it back again. It’s also great in focusing everybody. All they need to do is think for each idea they have how will it affect the metric.

Lately, when approaching the design of a new metric, I started focusing on the value chain. Start with the input and expected output. This should be pretty straight forward from the problem statement.

Your high level metric should be something like ‘given X examples of an input, the solution will manage to cover y% with the following output’. It’s best also to break it down internally to some intermediate steps, especially if there are several teams involved. This way, if something goes wrong, it should be easy to identify where exactly the problem has occurred. Make sure though the each sub-metric will still focus around value creation.

To sum it up, probably the above technique will require some more time when designing a new project/module, but in the long run, you get to evaluate it and make sure you focus your resources around the right areas. You’re the CEO of the product – that’s the type of great news you should be hearing:)

One thought on “The Importance of Mentioning the Business Justification in Each Design

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s