How a SDM shoots at a moving target

“Hi Bob, I saw your team started design work on feature X. I thought your top priority right now is feature Y. How come you decided to start X in the middle of Y?” I asked a SDM.

“Yeah we can’t really get Y going until Product Management finalizes their requirements. So I thought maybe we will design X first.”

“Hmm” I contemplated on Bob’s dilemma.

“It is a common project management problem indeed. We all know project Y is our most important feature of the year. But Product Management needs more time to get their thoughts together. On the other hand, we are doing ground breaking things nobody has done before in project Y. There are risks of unknown unknowns. Waiting on PM to finalize the decisions will only make the risks higher. We want to start the work on project Y as early as possible.

“But how do we start working on a project without finalizing the requirements? It is like shooting at a moving target!” Bob was not convinced.

“Well shooting at a moving target is definitely hard, but it is not impossible. It takes a lot of practice but as they say in shooting world: it is all about the lead!

We can apply the same technique in project management. We don’t know all the requirements of project Y, but we know some that won’t change anymore. We also know the non functional requirements that won’t come from PM: availability, scalability, extensibility, modularity, composability etc. We can pick the requirements that are not moving as a Minimum Viable Product (MVP), use it to drive non-functional system design and implementation.”

“So we should start writing design doc for project Y?”, Bob started to get it.

“Not necessarily. Writing document is a mechanism to artificulate the problem, requirements, it’s goal and the important design decisions. Depending on the nature of the project, early prototype combined with writing design document can be a good way to mitigate the unknown unknowns. But sometimes a snapshot of a whiteboard session is sufficient to start the prototype.”

“But what about we make wrong decisions on the design? Shouldn’t we do design reviews? ”, Bob asked.

“It is really up to you. Spending a long time on a design document does not make it a good design automatically. Software engineering is more like painting - you sketch layer after layer, correcting the mistakes you made is part of the iterative process. The important thing is to differentiate two way door decisions vs. one way door ones. Two way door decisions are either the things we will do no matter how the unknown requirements will be, or the things we can easily redo. One way door decisions are hard to revert therefore we often need more time and more data. But most decisions are two way doors, bias for action is the right mindset most of the time.

If the target is moving, take a lead and shoot! Missing the target is fine, we learn, and try again. You will never hit the target if you never try!”