Why vs. Why now

I recently read an article that said teams should ask “why now” instead of “why” when making large product and engineering decisions. It struck a chord.

There is a cost associated with all things software engineering, in house engineering is not an infinite resource.

Why

When the question of why we need a “feature” is asked I have found it is usually backed by two types of reasoning;

• Feature parity to competitor
• Belief customers need said feature

Engineering teams are busier than ever, corporate want to manage costs and see gains more than ever and this gives us a problem; we cannot build everything now.

Why now

There is fierce competition when it comes to a business that has a core function based on building software. Startups and small companies can sweep in quickly and rapidly which will have a costly consequence. Some thought provokers that you can dig into when deciding what to build now and prioritise

• What other work would be impacted if we built now
• Is there a simpler solution that will serve the core purpose of the feature
• Are we solving a problem that does not yet exist
• Return on investment if done now vs 6 months out
• Can we A/B test a “non working” example to gather predicted usage

Nobody likes to say no but if the rewards are small when building now vs delaying, the best answer may be to say no.