Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery. Engineers are often reluctant to participate in discovery. This is only natural: Through years of bad habits, many of us have shown engineers that we only value them for the code they can write.
This is a common mistake that Teresa addressed in a Core Concepts post, saying “We’ve spent the past 30+ years asking engineers to be order takers. We’ve often shut down their ideas before they can fully explain them. We so easily fall back to asking them to just deliver what we asked for.”
But there are many reasons why engineers are one of the essential members of the product trio. Engineers will hear different insights during your customer interviews. Their unique perspective means they will select different data, attach different meanings to it, make different assumptions, and draw different conclusions. And this is a good thing. Their perspective is valid and can lead to meaningful product improvements.
Engineers often generate the best solutions. This is because they have a depth of knowledge of what’s possible technically. But this only works when it’s coupled with a depth of knowledge of the customer’s context. And the best way for them to acquire this? By getting involved in continuous discovery.
Teresa has already written at length on this topic, so be sure to check out Why Engineers Should Participate in Discovery to learn more.
Even if you agree with these points, you might still feel like there are a few steps between the theory and practice. How do you actually get engineers to participate in discovery? For this Product in Practice, we caught up with Ellen Juhlin to hear some of the specific steps she’s taken to invite engineers into the discovery process and some of the quick wins she’s experienced so far.
Have your own Product in Practice story you’d like to share? Submit your story here.
A Quick Introduction to Ellen and Her Continuous Discovery Journey
Ellen is the Senior Director of Product Management at Orion Labs, a B2B company that offers voice communication to teams in industries like hospitality, retail, transportation, logistics, and security. Their core product offers instant voice communication like a walkie-talkie, but reinvented so it can be integrated with other web services and offer more context like location and online status. “It’s a complex platform that allows teams to stay in touch and there are a lot of possibilities for integration beyond that,” says Ellen.
A utility worker uses the Orion app on his phone to communicate with his colleagues.
During Ellen’s eight years at Orion Labs, she’s seen a lot of change, both in terms of the company’s evolution from B2C to B2B as well as in her own understanding and adoption of continuous discovery practices.
Since participating in a Product Talk Master Class about a year ago, Ellen says she’s been obsessed with aligning business goals to product value for her customers and has been working to implement pieces of that over time at her company.
This isn’t always an easy or simple process. “It’s hard to take a whole book or a six-week class and instantly download that into all my coworkers’ brains, so it’s been an education process as well, but every time I introduce a new piece of it, it seems to catch on really quickly, and their response is, ‘Oh right, this makes a lot of sense!’”
Introducing Continuous Discovery to the Engineers
To get engineers involved in continuous discovery, Ellen began by inviting them to participate in customer interviews. “Teresa’s process for interviewing and specifically asking about past behavior really changed how we went about talking to customers,” says Ellen. “We’d do an interview planning session, often with customer success and an engineer or two to identify what we wanted to learn and we were often able to include an engineer in the interview itself as a listener or note-taker or both.”
Teresa’s process for interviewing and specifically asking about past behavior really changed how we went about talking to customers. – Tweet This
Once the engineers got more comfortable participating in interviews, the next iteration of their continuous discovery habits involved taking what they were hearing from customers and incorporating it into what they were building.
Ellen shares a specific example about missed messages. “We’d gotten several different pieces of feedback from customers about being aware that new messages had arrived and being able to respond to them. We walked through this with the engineers, starting with the opportunity, ‘We want to make it more apparent to the user if they missed a message when they stepped away for a moment.’”
The product trio did a few brainstorming sessions, picked a few things they wanted to develop further, and story mapped different solution paths. This process highlighted how valuable the engineers’ contribution was. “We definitely got some ideas from the engineers that we wouldn’t have considered just within a product team, like using motion detection on the device as part of a possible solution, so it was great to get that engagement and ideation,” says Ellen. “It was good to have ideas from both sides and follow through with options of how we could solve this for the customer.”
We definitely got some ideas from the engineers that we wouldn’t have considered just within a product team, so it was great to get that engagement and ideation. – Tweet This
Ellen took the engineers through several activities, including reviewing interview notes and an opportunity subset before brainstorming, grouping, and dot voting on the solutions to explore. Click the image to see a larger version.
Inviting Engineers to Participate in Assumption Mapping
The next step of building out the engineers’ continuous discovery habits involved inviting them to participate in assumption mapping for the opportunity of optimizing direct messages. Ellen says they examined different risks and things they’d have to test out. For example, they looked at assumptions like, “The user will know how to find this feature,” “The user will know what it means when a specific thing happens in the UI,” or “There’s a feature that we think is cool but we’re not sure how to introduce it to people.”
After coming up with their list of assumptions, they started looking for ways to verify them. Here’s how Ellen describes this process: “Let’s see if there’s a way to verify our assumption that the feature could be really helpful and keep the education part for further down the line, because if it’s not actually useful, making a nice dialogue box doesn’t help anything.”
The engineers caught on quickly, but since they were still learning the process, they might sometimes struggle to know which concerns to focus on at which points. Ellen wanted to keep them focused on the process, so sometimes she would help guide them. “Every time someone said, ‘But how will we do X?’ I would reframe that as, ‘Let’s add an assumption that we will be able to do X and then decide where that goes in our assumption map.’”
This is an example of an assumption map Ellen created with the engineers. Ellen says this tool helped to reframe discussions and keep everyone focused on the same part of the continuous discovery process. Click the image to see a larger version.
A Major Win: The Engineers Get Invested in Continuous Discovery
At this stage, something clicked with the engineers. Ellen and other product managers were talking through a few ideas that were still a little vague and risky (but could potentially have a big impact) with the engineers. And even though the engineers were still relatively new to the process, it had become natural to start talking about risks in terms of assumptions they were making. They would reframe a statement like, “Maybe we should just add a setting for this so people know what it does” to “We’re making some assumptions that we’ll be able to educate the user about what this feature does and how to access it.” This reframing helped them more easily identify specific areas to run usability tests.
When they were discussing the riskiest part of the feature, the Android team said, “Well, we can actually just build this one piece in an hour and put it in a test build.” This was a major win for Ellen. “This was huge,” she says, “because if we had just asked for that directly, without talking through the assumptions with them first, there would have been a lot of questions and concerns about how users can access it, or know what it does, etc., and now we can tackle the top right of our assumptions chart right off the bat!”
Ellen knows that bringing engineers along throughout the whole discovery process was key. “Because engineers had been through that whole brainstorming and story mapping, they said, ‘This is the most promising direction, and this is something we could user test with some people internally and implement this one key piece of it pretty quickly.’”
Because engineers had been through brainstorming and story mapping, they were able to identify the most promising direction and find a way to implement one key piece of it pretty quickly. – Tweet This
Then, when the engineers joined the user testing sessions, it was much easier to achieve alignment among the product trio. Ellen shares an example of a sound cue which is used in different ways within the app. If the product team had simply asked the engineers to change the sound cue, the engineers may have pushed back. But since they’d been active participants in user testing, they agreed right away. “It was really clear to them, having gone through the process and then seeing people use it, these were the next couple things that we need to tweak to really validate that this solution is right,” says Ellen.
This experience has taught Ellen how critical it is to involve engineers in discovery. They’re much more invested in the decision-making process and can proactively suggest ways of testing assumptions, like in this example.
Key Learnings and Takeaways
If you’re inspired by Ellen’s story and hoping to get your own engineers more involved in continuous discovery, Ellen has a few tips to share. First, she suggests starting with one or two engineers instead of trying to educate the whole engineering department at once, especially if they haven’t gone through the process before. “There are going to be questions about the process and comments or questions about things that are not related to what you’re working on,” explains Ellen. You’ll need to redirect and help people stay focused on the task at hand. This can quickly become overwhelming if you’re involving too many people.
Also, keep in mind that this won’t always be a linear process. “Don’t be afraid to jump back and forth between different steps of the process,” says Ellen. “The point is not to lock things in stone and never look at it again, but to go back and revisit as you learn more and have new ideas. There’s going to be a lot of going back to previous steps, iterating, going forward, going back, and that all helps make sure that when you get to the end of the process, you’ve truly validated the thing that you want to move forward with.”
Don’t be afraid to jump back and forth between different steps of the process. The point is not to lock things in stone and never look at it again, but to go back and revisit as you learn more. – Tweet This
Finally, Ellen recommends keeping engineers in the loop when it comes to business outcome mapping. While everyone hears about high-level business goals at all hands meetings, it can be useful to remind them how these goals translate into development efforts. “It’s not anything that I’m expecting people to memorize or recite at a moment’s notice, but just as a quarterly reminder or refresher, this is why we’re doing these things, and that can hopefully help people prioritize in their day-to-day work as well,” explains Ellen.
