Bringing the Continuous Discovery Habits to Orion Labs with Ellen Juhlin

Introduction

In this section, Ellen introduces herself and her company, Orion. She explains the nature of their product and their typical customers.

• Orion provides voice communication solutions for frontline workers.

• The product is used by people working in retail stores, hotels, bus drivers, etc.

• The product helps teams coordinate with each other in real-time.

Introduction to Continuous Discovery

In this section, Ellen talks about how she got introduced to continuous discovery through a master class. She also discusses the distinction between discovery and delivery.

• Ellen heard about continuous discovery from a friend who had taken the master class.

• The master class helped her understand the process better and gave structure to what she was already doing.

• Continuous discovery is different from delivery because it focuses on understanding customer needs before building solutions.

Company Work During Pandemic

In this section, Ellen talks about how her team was working during the pandemic and how they were figuring out remote work.

• When Ellen took the master class, they had just transitioned to remote work due to the pandemic.

• They had previously iterated on how to do product roadmap discussions as their company grew.

• They were still figuring out how to work remotely effectively.

Planning Cycles and Prioritization

The speaker discusses how they prioritize tasks for their engineering team, including the use of six-week planning cycles. However, they note that this approach was still missing a connection to the overall business strategy.

• A product manager on the speaker's team proposed using six-week planning cycles to constrain priority levels.

• This approach helped focus on specific tasks for the next six weeks but did not tie back to the business strategy.

• There were often fire drills based on investor or competitor ideas that would interrupt planned sprints.

• As a startup grows, there is a transition towards putting more practice around product decision-making.

Decision-Making Process

The speaker discusses how decisions about what to build are made and who is responsible for making them.

• The executive team, including the speaker as part of marketing and sales, decided on output priorities.

• Sprint cycles were already in place but often got interrupted by new customer requests or ideas.

• The company had changing rules over time as it grew.

• In B2B contexts where you're not building for yourself, it's important to get into customers' needs and figure out what they really need.

Customer Research

The speaker talks about how they learned about their customers' needs before taking a Master Class.

• The company had done consumer research up front when starting as B2C.

• They conducted focus groups, taxi ride-alongs, UX prototype testing, etc., to learn how people interact with walkie-talkie apps.

• When transitioning to B2B, they needed to understand how different types of customers used walkie-talkies (e.g., security teams vs. retail stores).

• They got some information from the customer success team but had a protective layer between sales and CS.

The Role of Engineers in Prioritization Discussions

In this section, the speaker discusses the role of engineers in prioritization discussions and how they were involved in the process.

Engineers' Role in Customer Hunting

• The success team was hunting for customers and trying to figure out who needs this B2B app.

• They were trying to bring back information on what customers need for them to build it.

• The speaker was bridging the day-to-day with the engineering managers and part of the scrum process as well.

Prioritization Discussions

• The company had a head of Engineering as part of their prioritization discussions.

• They had a huge list of things that they wanted to do, which was broken up by component or customer.

• Before starting six-week cycles, they had meetings every two weeks that were priority meetings. However, these meetings got bigger and bigger over time, making them unproductive.

• The six-week process was one step in the right direction towards clamping down on priorities.

Learning About Continuous Discovery Framework

In this section, the speaker talks about learning about continuous discovery framework and how it helped them during a pilot project with a big customer.

Pilot Project with Big Customer

• When they started a pilot project with a big customer that had security teams in different campuses at sites around the world, they began using continuous discovery framework techniques.

• One of their product managers was also the project manager for this pilot so that they could get feedback directly from those trying out their product.

Using Storybase Interviewing Technique

• They used storybase interviewing technique to learn more about what customers were doing in their work.

• This technique helped them learn additional behaviors and patterns beyond just hearing what sales and customer success teams had to say.

English How to Bridge the Gap Between Product Managers and Customers

In this section, the speaker talks about how a product manager was able to get access to end-users by managing Gantt charts and spreadsheets. They also discuss how they introduced story-based interviewing techniques to their team.

Accessing End-Users

• The product manager on the speaker's team managed Gantt charts and spreadsheets, which gave them direct access to customers.

• This helped bridge the gap between product managers and customers, as it showed that talking to customers is not scary.

• The speaker found story-based interviewing techniques helpful in planning interviews based on story-based questions.

Introducing Story-Based Interviewing Techniques

• The speaker introduced story-based interviewing techniques to their team by practicing asking each other questions and giving feedback.

• Engineers were not involved in interviews at this point, but CS or salespeople would sometimes be present.

• One of the product managers on the speaker's team was also a designer for the mobile team.

English Introducing Outcomes into Priority Conversations

In this section, the speaker discusses how they introduced outcomes into priority conversations with their organization.

Linking Outcomes with Priorities

• The speaker's team started introducing outcomes into their priority roadmap by linking them together in a spreadsheet.

• They added outcomes such as winning big customers or increasing engagement or retention.

• This allowed them to introduce business strategy pieces into conversations about priority.

I apologize, but I cannot see any transcript or video to summarize. Please provide me with the necessary information so that I can assist you in creating a comprehensive and informative markdown file.

I apologize, but I cannot see any transcript or video to summarize. Please provide me with the necessary information so that I can assist you in creating a comprehensive and informative markdown file.

Brainstorming Solutions

In this section, the speaker talks about a working session where they brainstormed solutions and used active language to give structure to the conversation. They also discussed how to redirect energy without shutting it down.

Brainstorming Solutions

• The speaker helped their team through the process of brainstorming solutions.

• They used active language to give structure to the conversation and defined the solution at the story map level as an assumption.

• The speaker redirected energy without shutting it down by labeling ideas differently.

• They focused on figuring out pieces of the problem before jumping ahead.

Covering Ground in One Hour

In this section, the speaker discusses how they covered a lot of ground in one hour during their working session. They also talk about mixed feelings from some engineers and what happened after that meeting.

Covering Ground in One Hour

• The speaker covered a lot of ground in one hour during their working session.

• They started with an opportunity, brainstormed solutions, story mapped several ideas, and identified assumptions.

• There were mixed feelings from some engineers who felt unsure about participating or didn't know how best to participate.

Follow-Up Meeting

• After the first meeting, there was a follow-up meeting where they went deeper into assumptions and prioritized them using assumption mapping.

• New ideas were always welcome as maybe there's something better that they haven't thought of yet.

• During this meeting, they identified assumptions such as using the sensor on the tablet and pausing notifications for some reason.

• They put the assumptions on a known versus unknown and important versus unimportant scale.

Conclusion

In this section, the speaker concludes by discussing how they were able to redirect energy without shutting it down and how new ideas are always welcome. They also talk about how engineers may feel unsure when learning a new process.

Conclusion

• The speaker was able to redirect energy without shutting it down during their working session.

• New ideas were always welcome as maybe there's something better that they haven't thought of yet.

• Engineers may feel unsure when learning a new process, but their ideas are not wrong.

Quick Reply Feature

In this section, the speaker talks about the process of creating a quick reply feature for direct messages. They discuss how they identified assumptions and tested the usefulness of the feature.

Identifying Assumptions

• The team identified an assumption that people would know they are replying to one person when the default is sending it to everybody.

• They also identified an assumption that the feature would be helpful for people.

Testing Assumptions

• To test whether the feature was useful, they built a prototype where the reply button is a direct message button for five or ten seconds after receiving a direct message.

• After testing internally with employees, they made some tweaks based on feedback and found that people really liked it.

Introducing Framework Pieces Gradually

In this section, the speaker discusses their approach to introducing new processes and frameworks gradually rather than all at once.

Matching Framework Pieces to Organization Needs

• The speaker matches different pieces of frameworks to how their organization works currently.

• They note that product managers were receptive to brainstorming and story mapping while engineers were more ready for solutioning and assumption mapping.

Experience with Stopping Everything for New Processes

• The speaker notes that in past experiences, stopping everything to introduce new processes was unsuccessful.

• They explain that slowing down or even having the perception of slowing down can get in the way of getting things done quickly.

Introducing Continuous Discovery

In this section, the speaker talks about how they introduced continuous discovery to their team and the challenges they faced.

Introducing Continuous Discovery

• The speaker wanted to introduce continuous discovery to their team but didn't want to teach 40 people all at once.

• They started by talking with different managers about interviewing, brainstorming, and solution mapping.

• The speaker found it challenging to ask everyone else to change the way they do business strategy when introducing outcomes versus outputs.

• The outcome discussion is still in process today.

Progress Made in Two and a Half Years

In this section, the speaker talks about the progress made in two and a half years since introducing continuous discovery.

Progress Made in Two and a Half Years

• The speaker starts all product strategy board meetings with an outcome map.

• They have successfully integrated story-based interviewing into customer conversations.

• They have introduced brainstorming for recent projects that will be launching soon.

Opportunity Solution Tree Brainstorm

In this section, the speaker talks about the opportunity solution tree brainstorming process and how it helped generate three different major solutions. The team identified assumptions for each solution, which helped facilitate decision-making.

Generating Solutions

• Facilitation was required to redirect energy into the process of generating new solutions.

• Sticky notes on a digital whiteboard were used to document ideas.

• Three different major solutions were generated through this process.

Identifying Assumptions

• Assumptions for each solution were identified and documented on sticky notes.

• This helped facilitate decision-making between back-end and client-side solutions.

• Having detailed information about each solution's assumptions allowed for more informed testing.

Benefits of Story Mapping and Assumption Testing

• Active externalizing of thinking through story mapping and assumption testing helps teams align around how a solution might work and what assumptions are being made.

• Even if teams don't run an assumption test, their solutions will be better by going through this process.

Impact of Process Changes

In this section, the speaker discusses how introducing habits in various places has impacted the organization's transformation. The new process has taken opinionating out of the equation, resulting in better alignment among team members.

Impact on Opinionating

• The new process has taken opinionating out of the equation when generating big media ideas that people have strong feelings about.

• Redirecting feelings and attention into a documented process helps shortcut concerns that may arise.

Benefits of Collaborative Work

• Having artifacts documenting collaborative work helps demonstrate that everyone contributed to generating ideas.

• This approach results in better alignment among team members.