Stop “protecting” your engineer’s time
“Product Discovery brings out people’s creativeness and provides a balanced opportunity for engineers to give their ideas.”
I’m an engineer by training and still code from time to time. Looking back, I’ve always been product managing and shaping concepts before I wrote code. I know deeply how valuable an engineer’s contribution can be early in the idea process.
Problem: Widespread Engineer Exclusion
Engineering leaders no longer include their engineers in developing the ideas they work on.
Leaders seem content to let the business folks work out the WHAT while engineering does the HOW. But this waterfall model of hand-offs has a dismal track record of innovation.
Instead, build morale and stimulate innovation by sending engineers into the Product Discovery phase where we develop raw ideas into valuable products.
The most successful tech companies involved engineers from the very beginning. These engineers did the HOW but also knew the WHY and actively shaped the WHAT...think Facebook, Google, Apple, Oracle, Microsoft and others.
This engineer isolation can happen in ANY size company. I’ve seen 10 person companies with a strict separation of hands-on keyboard engineers from Product teams.
Engineers bring differentiating, technology-based innovation because they know what is “just now possible.” The business side of the company simply cannot know enough about the underlying technology to do this.
Even worse than losing out on innovation, top engineers will leave. A great engineer wants a say in what they work on. They have ideas. They are curious and have great questions on the business aspects of products (not just the tech side). Top engineers will leave companies where they are not valued for their business opinions.
Solution: Include Engineers Sooner
“If you find out something in Discovery that doesn’t work out…at least you’ve saved OTHER engineers’ time by NOT building it.”
Put your engineers on a cross-functional team led by a Product Manager. Let the Product team (guided by company goals and metrics) determine what each engineer will work on. Don’t micromanage them in quarterly roadmap planning exercises.
This is hard for most Product and Engineering leaders.
When four of us started PowerReviews in 2005, we were convinced that we could enable every online retailer to offer their own product reviews service. But we had no idea how to do it.
I was an engineer then and along with the other founding engineer, we found emerging technologies (Iframes, AJAX, cross-domain communication, ORM, Postgres, etc.) that enabled PowerReviews to come into existence as one of the first website-embeddable, SaaS companies.
Our company strategy simply would not have been possible if the business folks had designed the product without us engineers. We needed to bring the “just now possible” technologies to enable our unusual business model.
Involving engineers upfront feels inefficient to leaders. Shouldn’t the engineer be writing code? Not right away…by shaping the idea in the first place, the engineer provides key information for making effective tradeoffs and avoids writing code that will never be used.
So what does this look like?
After we get buy-in from engineering and product execs, I invite an engineer to participate in the pre-engineering activities of Product Discovery. This engineer does not need to be an architect or even a lead engineer. They just need to have an open mind and be interested in shaping future products.
Together, the engineer, product manager and designer form the core Product Discovery team.
They conduct and participate in Product Discovery sessions that include understanding the user journey, finding users’ top problems and of course creating solutions. Everyone creates their own solutions by sketching independently and exploring their own ideas. Then we come together to decide on a few finalists. These finalists get exposed to target customers in user testing. Then we refine or discard and move on.
Tactics: What are the Steps to Engineer Inclusion
“I feel like engineers will spend less time developing software people won’t use because it has already been tested with users to prove it has value.”
In companies where engineers only write code, there are a few tactics to allocate time and enable them to break away to attend Product Discovery sessions.
This is advice from engineers on Product teams that I’ve embedded with.
Consistency drives engineer attendance. Keep the schedule for Discovery meetings at consistent times and days of the week. Setup user testing slots at a recurring time each week.
Spread the load. Maybe one Discovery cycle is attended by one engineer and the next cycle is attended by a different engineer. As long as they are on the same development team, then this is fine.
Socialize Product Discovery to all engineers. Telling ALL the engineers about Product Discovery will help them understand why ONE of their colleagues is not at their desk or not in one of the usual engineering meetings. Create an environment where it’s “okay” and even encouraged to attend Product Discovery meetings. This will help eliminate these inevitable Slack messages: “where are you”, “we’ve got stuff to do”, etc.
Formally allocate the engineer’s time. The Product Manager needs to work directly with the dev manager or scrum master to put stories or cards into the workflow system (Jira, etc) to allocate a certain amount of “points” or days for an engineer to be spent with the Product team doing Discovery. This will help the engineering teams plan their estimates and workload. And it will take the pressure off the engineer to do “two” jobs at the same time since you’ve correctly allocated her time. In the workflow systems, I’ve seen this called “Unavailable for work”, “Spike”, and “Product Discovery time”.
Who should be the Discovery Engineer? The engineer participating in Discovery can be any of the engineers from the delivery team assigned to the Product. It should be a hands-on keyboard engineer. If architects or engineering managers want to understand the process then they can join as well, but not in place of the hands-on keyboard engineer. Having a hands-on keyboard engineer ensures that the transition from Discovery to Delivery will be smooth. And these engineers are often closer to the technology used by the team. The Discovery engineer needs to be a willing participant who is interested in volunteering ideas, giving feedback and listening to customers. So having a growth mindset is often more important than knowledge of the company's stack. Most all engineers are excellent at knowing what they don't know and finding out what they don't know so if the particular engineer doesn't have an answer, then they will ask a colleague, ask Google or figure it out.
These simple tactics will increase engineer attendance and relieve external pressure on the engineer.
Caveats: Not every engineer will be comfortable in Discovery
Ambiguity is not for everyone. The ambiguity of participating in Discovery which is a messy process might turn off some engineers. The lack of clarity can be uncomfortable and doesn’t work well for all personalities especially for those who just want to know what needs to get done. Be sure to mentally prepare engineers for these types of sessions where the goal isn’t an estimation or a refined Jira ticket. This will allow them to space to be less output driven. Ideally, all engineers can participate but if some are really uncomfortable then don’t force them.
Inclusion is a two way process. Just as there are engineers that can contribute to the ideation phase (the “what”), there are Product Managers who can contribute to the technical process (the “how”). The blurring of the lines between roles is essential to successful, collaborative Product Discovery. Both sides can contribute, even if either retains ownership and final say on the what or how.
Results: Morale Improvement. Time Savings. A Return to Innovation.
Engineers who participate in Product Discovery have buy-in to what the team is going to create. They were there when the ideas were shaped. They are an ambassador to the larger engineering team when questions arise. They feel heard. And they know they have saved the time of their colleagues and made the product better by nudging (or shoving) the Product folks in a more innovative and smarter direction.
If I haven’t convinced you yet, listen to these Engineers who have participated in Discovery teams:
“I now know the reason, the what and the why of the product.”
“I have more sympathy for my colleagues in product development and design. Developing ideas is *really* hard to do.”
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 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.
