By the end of the project, we had done more than we probably needed to. Honestly, _far_ more than we needed to. The requirement had come down to build “Service X”, and the team rallied and pulled it off. But, in hindsight, I think we might have been able to deliver sooner – if I had put more effort into clarifying what success looked like for our stakeholders, and been more ruthless about stripping down the service to the bare essentials to meet that yardstick.
In a way, it is like that part of The Martian (a great book and a good movie) where the main character, marooned astronaut Mark Watney, has to strip everything he can from the sole surviving Mars Ascent Vehicle (MAV) in order to meet his rescuers high above the red planet. The weight of things like the hatch, chairs, dashboards, and nose cone of the MAV were so heavy that it limited the altitude the MAV could reach. Success (getting Mark off the red planet) was not going to be achieved with all that excess weight.
Engineering leads and managers face a similar situation frequently. Projects assigned to their teams are often not accompanied by a lot of clarity around what success looks like. A lot of assumptions end up being made unnecessarily. The success yardstick might be assumed to be a fully functioning, pressurized, climate controlled MAV with comfortable seating and spare spacesuits, when the actual success yardstick might simply be a means of getting a marooned astronaut into high orbit.
It comes down to engineering leads and managers to always be clarifying – to always be asking their stakeholders “Why?” – and to always be jettisoning (or at least postponing) unneeded weight – the earlier in the project the better.
We should always be asking:
- Why do we want to launch product or service X? And then ask why again. Unpack the why’s a few times. “Because the CEO said so” isn’t good enough. They have a “Why” too.
- What does success look like? What sorts of customers do we want to attract?
- What are we assuming about our customers’ mindsets? Where are we trying to read their minds without actually asking them what matters to them? Hint: your ability to read your customers’ minds is far, far weaker than you realize.
- What stakeholder requirements are based on their own assumptions (or worse, mind-reading) versus stakeholder requirements that are backed by validated insights? Drive stakeholders to back up their requirements with facts and data.
- What is the bare minimum our customers need? Do we really need to be able to provide multiple levels of service? Is there one level that we can start with first? OK, now ask again – within that level of service is there even more we can jettison? Repeat this often.
- How much time do we have? Why did you pick that deadline? What are the other events you’re trying to tie this product or service’s launch with
- How much money does this need to make in the first year? The second? What support costs are acceptable? Does everything we are doing support that? Why or why not? What can we jettison to reduce support costs?
- What customer acquisition cost is too high? What minimum long term value is expected? How soon must that value be realized? This can also help engineering get a sense of which features/services need to be streamlined and prioritized or written at all.
- How much flexibility or scalability does the system really need to support right now? Where are the requirements unclear, and where can we somewhat safely assume things are less likely to change? Over-engineering flexibility is expensive and slows velocity.
- How many new customers does this need to generate for us? What rate of churn is too high?
- What key metrics are needed to know if everything is meeting expectations?
Essentially, always be clarifying what success looks like. What the yardstick is.
What questions would you add to your repertoire when it comes to clarifying success with stakeholders and jettisoning unneeded scope? Where might you have excess weight on your project that is keeping you from the best velocity towards that first (or next) release? Where have you, your team or your stakeholders assumed complexity where it is unwarranted and doesn’t meet anyone’s actual yardsticks? What unessential effort is going to make the project possibly miss some critical rendezvous?
Props to Jeff for the constructive feedback that sparked this post.
Allen at Automattic 