You might be excluding your most innovative voices: why engineers are critical in product discovery

My team’s mission for the last year has been to reimagine one of Honor’s core pillars — matching the right caregivers with our clients, which will lead to the best outcomes. We took five consecutive swings at the problem, each uncovering new insights and inching us closer to our goal. Through a mix of rapid prototyping and fully productionized features, we’ve appreciably changed the trajectory of our client and business outcomes for the better.

Our year of building, discarding, iterating, and falling in love with the problem has culminated in a new operations tool that one of our long-tenured engineering leaders has designated “one of the most innovative products we’ve built over Honor’s 10-year existence.” I’m proud of what we’ve delivered (even the products we scrapped!). Yet, the most significant outcome has been developing our cross-functional team’s muscle around product discovery and delivery that we can apply to any future challenge.

The secret sauce? The determinant was inviting engineers into the early phases of discovery and ideation.

A common practice in software development is having the product manager and designer liaise with customers and stakeholders. While the engineers work on project A, the product manager and designer scope out project B. At some point, the product manager drafts a requirements document and socializes it with a designated engineer (tech lead). If we’re lucky, the requirements document isn’t already opinionated about a specific solution. The tech lead and product manager clarify and negotiate requirements, the tech lead drafts a solution, and the team participates in a project kickoff that includes requirements, the solution, and mocks. Cue grooming, plan it poker, etc.

Sound familiar? I’ve been an engineer on teams that implemented that process. I even perpetuated that method when I first stepped into management. The metrics by which engineering was held accountable (namely velocity, which is expected to increase over time) led to this implicit pressure to maximize the raw output of every engineer. In other words, let’s optimize the “hands on keyboard” time for engineers by minimizing the “disruption” that is product discovery time.

While this approach isn’t necessarily incorrect, it risks underutilizing your engineers’ abilities and is likely leading to inferior products that take longer to build. Instead, I suggest:

• Avoid committing to solutions in a silo
• Engineers should observe and interact with customers
• The desired outcome and any constraints need to be clear

Avoid committing to solutions in a silo

Engineers have an indispensable perspective because they understand how much it costs to build something, how features work, and what is possible. Without having engineers in the room alongside product and design, I’ve seen low-cost, high-return investments overlooked. The opposite is also true — engineers are pitched complex solutions that lead to sticker shock at the estimate, which wastes more time because then we backtrack to come up with solutions together.

When possible, resist the urge to have part of the team work ahead of the rest. I’ve found that the time saved by the engineers that are not included is an illusion. At best, you pay the cost later to catch them up. At worst, the excluded engineers have an even better idea, and you’ve wasted additional time getting attached to the original idea.

Engineers should observe and interact with customers

Ensuring the team has regular visibility into the customer’s experience with the product is non-negotiable, especially when you are building and testing a new concept. Within our team, our designer and product manager met daily with at least one customer to observe them using the product. The daily cadence was important because we were shipping updates multiple times a week in response to what we were learning in our shadowing sessions, but I’d expect a weekly or bi-weekly cadence to be appropriate for other teams. Depending on the project phase, engineers either join the call and engage with customers directly or watch the recording after the fact.

Face time with customers has been hugely motivating for the engineering team as well as our customers. We’ve been able to develop deep trust with them due to our short feedback-to-delivery cycles and make them feel heard. It’s a lot easier to be successful when your customers want to help you succeed.

It’s important to note that while customer feedback is gold, what they ask for may not be the best solution or address the underlying problem. Being able to observe and probe in real-time allows the team to discover the true problems to solve far better than a requirements document.

The desired outcome and any constraints need to be clear

“The main thing is to keep the main thing the main thing”

— Stephen Covey

The last puzzle piece is aligning the team on a specific outcome to achieve. In our case, we had a two-part mission: 1) build a new product that moved a specific metric down while keeping control metrics stable in two test markets, and 2) scale the product to the entire platform by Q3 2024.

These guidelines were freeing in their own way; we had the green light to give our test markets our full attention and had clear success indicators with the metrics. We identified the right customers and stakeholders to partner with who were on board with trying something unproven. This allowed us to ship code rapidly in the first phase to learn and test our hypotheses without slowing down for typical engineering tenets like automated tests and clean code. We were strictly in experimental mode and prepared to throw everything away once we knew what worked. We started from scratch again in January, equipped with rich customer and product insights.

As a manager, one of my most important responsibilities is ensuring the team understands business goals and where our team falls in the big picture. This context allows the team to make strategic tradeoffs that affect which solution we ultimately implement. Everyone knows we want to deliver business value as quickly as possible, but knowledge about what product offerings the company wants to double down on in the future can sway where optimize for speed and where we build for longevity.

I’ll end with this quote from Marty Cagan, a product thought leader who advocates for engineering-led organizations.

I’m not suggesting that you put your engineers on a pedestal. They are ordinary people like the rest of us. But I am suggesting that you treat them like the first-class members of the product teams they need to be.

Will you invite us in?

Jocelyn Keung is a senior engineering manager at Honor, a healthtech startup working to improve in-home care. Are you interested in changing the aging experience with us? Browse open positions on our job board.