Involve Engineering Earlier
Photo by Alain Pham on Unsplash
Incentives drive behavior and engineers are incentivized to write code. It’s one of the few jobs only they can do. Scarcity determines value — their time is most precious. It’s also the most obvious measure of productivity — the visible work product easily seen and appreciated.
For this reason, when you ask engineering to be involved in product discovery — the process of figuring out what to build, instead of just building it, you understandably get a raised eyebrow. After all, isn’t that the product manager’s job?
As we’ve seen before, team roles and our closely-held identities thwart our attempt at making something great. Discovery is a team effort — UX, PM, and Engineering, among others, need to shape the product direction.
More than anyone on the team, engineers know the product actually works, under the hood. Not only do they know what’s possible, but they also bring a rigorous mind to problems by nature of who they are, and the work they do every day. Engineers catch details others miss.
The unspoken objection is that engineers have better things to do — we all know that writing code the highest and best use of their time, right? Well, in practice, engineering’s involvement early can actually speed the overall flow through the system.
In discovery, technical questions always arise, and having a team member who can vet them in real-time, or quickly get a bead on the rough answer, facilitates course correction early, when you want it. It’s why we call early change learning and later change waste.
Without involvement, engineers are handed the answer key without any participation in the group discussion, lectures, quizzes, or homework. All the rich context of how and why is lost. You can’t replicate months of thoughtful work with cliff’s notes (eg requirements doc). How well could you learn and apply Calculus if your textbook only had the answer key?
This does not mean every engineer should abandon their IDE for a whiteboard or customer ride-a-long. Often a team lead or architect can serve in this advisory capacity. Some involvement from development is much better than none.
Of course, this approach isn’t a panacea — at some point, the proverbial requirements baton is still handed to a development team. The difference is that now, engineering isn’t facing a cold start. One of their own was involved in the messy process of choosing the solution. This gives them a sense of trust that what they are embarking on has been thoroughly considered. Nothing smoothes a transition like trust.
You might be wondering- isn’t this expensive? Don’t we really want engineers coding? Well, yes, assuming they are working on the right things! If we ship something no one wants, is that useful? Of course not — it’s the worst kind of waste. The waste that we keep paying for year after year. Better the factory stays idle than churn out junk no one wants or needs on a rigorous schedule.
If you want to improve your odds of building something people want, involve engineering earlier.
Like articles on building product? Subscribe to receive by email.