When deciding to build new features and functionality, one of the most important questions product managers and non-technical founders ask engineers is, “how long will this take?”
The question usually comes as the last step of the decision making process for a given feature/product. Prior to popping “the question”, the asker will most likely have already talked to all the other stakeholders and gathered initial thoughts on the idea. Once an initiative has received interest from stakeholders, the next step is figuring out how many resources will be needed to build it. In software development, resources essentially means engineering and design time. Since design should be ahead of engineering and is more straight-forward, engineering time is the main investment.
And here’s why.
If an engineer says it will take him or her 6 months to build — assuming that engineer earns $120k per year — the new feature will cost $60k in engineering time alone. If the engineer is off by 2 months, that’s an extra $20k for the project (plus the opportunity cost of not being able to assign the engineer to work on other things).
The above way of estimating work in a megalithic chunk of 6 months is likely to be wrong. And as we just covered, being wrong with work estimates is very expensive.
Great engineers have a more piece-meal approach to estimating work. It’s not that these engineers are necessarily smarter or more talented. These engineers simply have a more realistic understanding of their own software development abilities and can anticipate challenges that will potentially stall their progress and communicate any help they might need in advance.
By breaking down a software project into phases, great engineers are able to estimate the amount of work for the each piece of the project. When engineers have the ability to both break down the project into pieces and then estimate the amount of work for each piece, the resulting timeline for the project is likely to be more correct.
This process will work even better on teams where you have multiple engineers who are familiar with your codebase. Simply get a few engineers in the room (block off a couple hours on the calendar to be safe), review the phases of the project and the amount of work estimated for each phase, and ask an open-ended question, “how does that sound?”. Then shut up, take notes, and let them talk through it. At the end of their discussion, you’ll end up with as good an estimate of work as you can feasibly get before starting development.
Non-technical founders and product managers are limited in a lot of aspects of software development but this process is one of the best ways I’ve seen for working around the “I can’t code so I don’t understand how long it will take” problem.
The best part about this method is that if you do it enough times, you start developing one of the best product management superpowers: an innate ability to correctly estimate how much time something will take to build.
Thanks for reading! If you enjoyed this, it’d be awesome if you hit recommend : )
P.S.
getting software developers in a room and asking them to think through solving a problem is one of the best parts of working in tech. This gives you a taste for the dynamic.