Use “more” Engineer Time Sooner to Reduce Total Engineering Time
Is asking for an estimate the first time you talk to an engineer?
This is too late.
Bringing an engineer into early conversations helps avoid rework and surprises, enable smarter trade offs, and encourage technology-based improvements and innovation.
By using “more” engineer time sooner in the process, you can reduce the total engineering time spent on a project.
To understand what’s happening in development these days, I interviewed senior engineers with an accumulated 100+ years of experience either starting successful companies or succeeding in bigger tech companies such as PagerDuty and Google.
They describe being excluded from the ideation, design and definition of the products that they work on.
Problem: Working with an engineer too late in the process
There’s a sinking feeling for an engineer when they realize that they could have saved the Product team time or that the underlying technology doesn’t support their ideas.
And most times, it’s too late to bring up a new way to solve the problem...especially since the engineer may not even know what problem or target customer that the Product team is solving for.
When companies and Product teams exclude engineers from the idea development phase, they risk:
Increasing the total time of the project
Generating wildly inaccurate estimates
Decreasing engineer morale
They lose out on:
Technology-based innovation
Increasing the technology acumen of the whole team
Knowing what’s easy or hard
Knowing what’s possible with the current state of technology
Product teams often play the “game of operator” where the purpose of a project gets lost during the handoff of documents from one person to another to another and so on. This is waterfall development and it’s too commonly practiced.
“I’d prefer having a better idea of the actual goal of a project instead of the interpreted requirements. Currently there is oftentimes a requirement that doesn’t meet the actual goal of what the business owner is trying to achieve. If we are aware of the end goal there is usually a different approach that may be easier to achieve the same goals.”
Product teams falsely use the What vs How argument to keep folks in their silos. The senior engineers I interviewed and the high performing teams I work with always blur the What vs How distinctions to get the best possible product.These self-imposed limitations cause technology-based innovation to shut down.
“At my current job I usually get a high fidelity clickable prototype. Often the designer hasn’t thought of all the use cases or doesn’t understand what’s possible with the underlying technology.”
Solution: Don’t Write More. Collaborate More.
When engineers describe being out of the loop, the first reaction by Product teams is to create more detailed written deliverables.
Getting a colleague up to speed is never as simple as writing a better user story or adding another section to your requirements document.
This problem is structural.
A completely exhaustive requirements document or clickable prototype will still only represent the knowledge and minds of non-engineers.
And these overly detailed documents take too long to create and polish and the longer they get the less likely they are to be read by the receiver.
In addition, these detailed deliverables usually leave out the context for the solution (customer problem/opportunity, company objective, metric outcome, target user, etc).
They think “Why would the engineer need to know this?” and they “throw it over the wall”...hoping for the best.
Whether it’s a PRD/Requirements document or a high fidelity clickable prototype, neither provides the context to engage the best efforts and ideas of your engineers.
The solution is to add an engineer to the Product team discussions at the very beginning of the process.
“Involve engineers during the ideation process since many issues can be filtered out earlier, we can reduce rework and also engineers will be thrilled when it enters the development stage. Execs: Make sure the engineers stay motivated.”
“Treat us as partners, not resources.”
Benefits: Use “more” engineer time sooner to reduce total engineering time
So when do you bring in an engineer?
Pretty much right away.
At first, teams will see this as using “more” engineering time.
In practice however, this early involvement reduces the total engineering time spent on a project by avoiding rework and iterating more often.
Iterating in design takes days instead of the weeks or months that it takes engineering to create iterations.
It uses less total engineering time, since this upfront work (we call it Product Discovery) is done with one engineer whereas problems spotted later in the process involve an entire team of engineers.
Early on, an engineer can spot logic problems, technical feasibility problems and can suggest enabling technologies or methods that achieve solutions faster, better and/or more easily.
In fact, Product teams “create” more time by achieving increased productivity when engineers feel true ownership of the solution itself, not just its implementation.
So you save time and “create” time by involving engineers sooner.
This is not a new idea but it’s notable that successful senior engineers want to receive less information, sooner in the process. They see benefits to the project, the company and the team by participating early and helping design the solution not just build it.
You gain these crucial benefits when involving engineers early in the process:
Shorter total project time. It’s faster to iterate ideas in design. Products that are iterated in design have less rework and back forth after the Sprint starts.
More accurate estimates. It’s easier to estimate the time to code a solution when the engineer has an understanding of the project from participating in working sessions, not just reading the final document.
Increased engineer morale. The engineer has more ownership and buy-in of solutions that are partly or wholly theirs. They act as an ambassador for the project and can represent the reasoning for decisions to other engineers.
Learn what’s possible. There may be things you don’t even know are doable and your engineers can enlighten you.
Identify trade offs earlier. Learn what's easy vs hard sooner. Software is not inherently flexible. Business users are awful at knowing what’s hard and what’s easy. If a similar solution can get to market much faster, the business users might prefer that speed over having every detail as they envisioned.
Increasing the technology acumen of the whole team. Product Managers and Designers can and should learn more and more about the technology that is relevant to their subject matter area. They can develop and refine their technology intuition. They get better at solutioning by spending time discussing technology trade offs and innovations with engineers.
Read this article for an example of working together in the ideation phase that includes engineering. Product Discovery workflow: Collaborate before deliverables exist. Iterate before high fidelity.
Caveats: Not all engineers enjoy early collaboration
Many times engineers will say they want to be involved in early stages.
But their involvement is not always easy. They are usually busy with current deliverables. So we need to account in advance for their time spent in early collaboration.
In addition, engineers may not appreciate the messiness, ambiguity and lack of quantitative data that occur in the early days of a project. So we need to create a safe intellectual space where discussions can be exploratory and non-committal.
Engineers may also disagree so fervently with the project that it starts to split the group apart. It’s a smart business practice to get a cross-functional team working together on new ideas but in the end there needs to be a decision maker that is allowed the space to move a project forward. Navigating these disagreements successfully is a crucial skill of the Product Manager.
Read more about involving engineers in the idea development process: Stop “protecting” your engineers
Final Thoughts
“Ask engineers questions, get them involved”
And of course, always validate with customers...this article has been focused on engineer involvement but make sure to include the voice of the customer early and often.
Jim knows how to build successful teams and products from scratch.
He co-founded PowerReviews, a B2B2C product reviews SaaS platform, that had an exit in 2012 for $168 million at a 13x multiple. In the early days of the web, he product managed and architected one of the original ecommerce sites that had a $66 million IPO in 1999, online sporting goods retailer Fogdog.com.
For his Product teams, he’s created a curriculum and training program that pulls from his 20+ years of experience and the best minds in Product Management. In addition, he relies on his software engineering background and experience to bridge the gap between their Product and Engineering teams. He graduated from Stanford University with a degree in Computer Science.
Jim is based in San Francisco and works with clients from 2 to 20,000 employees in a variety of industries and business models. Previous clients include VSP Global, PagerDuty, Dictionary.com, and Hallmark. He’s also worked with startups in machine learning, API development, computer vision, payments and digital health.
