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. Saying no is a huge part of excelling in your product practice. If you say yes to every request that comes your way—whether from customers, salespeople, or executives—you can quickly get overwhelmed and lose focus.
But this isn’t always easy. Product people naturally want to solve any problems they’re presented with. Especially when you know it’s just a small request that wouldn’t take too much time to build.
Of course there’s always a tradeoff. Anytime you say yes to one task, it means you’re saying no to—or at least postponing—several others.
Anytime you say yes to one task, it means you’re saying no to—or at least postponing—several others. – Tweet This
So how do you know when to say no? And what happens if you change your mind somewhere down the line and want to change your answer to yes?
Continuous discovery can help. Since you’re starting with a clear desired outcome, it’s easier to say no to any requests that aren’t aligned with your outcome. And using tools like the opportunity solution tree can help you visualize your thinking so stakeholders better understand what you’re focusing on and why. This means you can spend less time telling them why you’re not moving forward with a random request and focus your attention on activities that impact your outcome.
Today’s Product in Practice showcases how one product manager, Helena Jeret-Mäe, initially said no to the idea of building a particular feature stakeholders had been requesting. But by using continuous discovery habits to slowly chip away at the opportunity, she eventually ended up in a place where she was comfortable saying yes.
Have your own Product in Practice story you’d like to share? Submit your story here.
Meet the Continuous Discovery Champion, Helena Jeret-Mäe
Meet the continuous discovery champion, Helena Jeret-Mäe.
Helena is a product and project manager at Singularity Creations, where she wrangles a few different apps while wearing different hats. Her main focus (and what we’ll be exploring in detail in this Product in Practice) is an asynchronous coaching platform that gives coachees the flexibility to engage with coaching content whenever and wherever it’s convenient. Their current customers operate in the field of education where they coach their clients (who are teachers) on how to use their educational program and tools.
When Helena joined her company in the spring of 2021, she says the product delivery process involved building a lot of hypothetically relevant features until they ran out of steam because they couldn’t increase adoption. It tended to be a one-dimensional flow of information from the client to the product team. Helena quickly recognized something needed to change: “I knew I wanted to nudge them away from that and I started realizing I must not be the first person to face this problem.” So she began an educational journey, listening to podcasts and reading about product discovery best practices. Eventually she found Continuous Discovery Habits and signed up for the Product Talk Opportunity Mapping course.
The Old Way of Working: A Brief Example
To help illustrate how continuous discovery has transformed her approach to work, Helena says, “I have this one particular thing that’s still in the product that’s completely useless.” Early in her time at Singularity Creations, a customer asked them to add a field to the coaching platform to hold a link. “I realized at the time that I wanted to say no, but I didn’t have any usable information from actual use cases and the customer was hypothetically saying they would need it.” So they built the field. “And to this day it’s never been used,” says Helena.
Looking back on this experience, Helena sees how her perspective has changed. “In my mind, I didn’t have this model where we could say, ‘This is an idea. Let’s break it down. How can we tell if it would be worth it for the customer?’” And since it was a small ask—just one field—they added it. And if nothing else, this box helps reinforce the importance of continuous discovery to Helena. She says, “It doesn’t bother anyone, but it reminds me that at that time I didn’t have a way to process incoming requests in a context which helps to compare and contrast them in a structured way.”
Using Continuous Discovery to Break a Big Problem into Small, Manageable Pieces
Helena says the Product Talk Opportunity Mapping course led to a breakthrough in the way she thought about discovery: “I felt like I finally had a way to structure things in my head.” And what stood out to her most was the iterative nature of continuous discovery. Instead of tackling one big problem with one big solution, she could break it into small opportunities which she could validate through quick tests. Let’s dive into one specific feature to see how Helena applied these concepts to her work.
With continuous discovery, I felt like I finally had a way to structure things in my head. – Tweet This
“We had learned about a year ago that the users in the system needed to nudge other users they were coaching who were falling behind,” says Helena. At the time, there was no way to do that in the system. Coaches could email coachees outside of the system, but since the information on what they were falling behind on and by how much was in the system, it made sense to add some capability there.
This simple opportunity solution tree captures how Helena was thinking about messaging at the beginning of this process.
At that time, Helena made the conscious choice not to build a full-fledged messaging system within the platform. She looked for small, cheap ways to add the nudging feature and validate the idea. “We gave the users a small box and a text button for each user they needed to nudge,” explains Helena. “Our developer was smart enough to say we could bootstrap this solution upon notifications that already live in the system and notify the users about certain events, like something was completed or something was added. So what we did was have the users send notifications to each other disguised as messages.”
In this first iteration, it was just a text box with a 500-character limit and a send button. Users couldn’t see what they had sent, so there was no history. The recipient of the message could only read the message and couldn’t respond. This feature was well received—the coaches were thrilled to be able to communicate with coachees in this manner.
In its first iteration, the chat feature was just a text box with a 500-character limit and a “send” button.
After this first iteration, Helena spent time observing the users’ actions in LogRocket, where she saw that they copied and pasted the same message for everybody that they had to send a message to. Even though users hadn’t complained about this explicitly, Helena added the ability to send a message to an entire group in the next iteration. It still didn’t have all the features of a group chat—it was still based on notifications, so it wasn’t possible to show the history of messages a coach had sent and there was no back and forth history in the chat. “It was clunky, but it worked,” says Helena.
Around this time, Helena began talking to customers to see how they used it. And what started coming up was when the user had sent a message, they would say, “I can’t remember when and what exactly I had sent to this person.” At this stage, Helena went back to the drawing board and asked, “If we had to make it so they could see the history and those messages they had sent, then what kind of solution would make sense?”
The product team found themselves at a crossroads: Should they continue bootstrapping or should they actually build a messaging system? By this point, they’d made several small iterations on the bootstrapped version and they’d had the opportunity to talk with users and observe their sessions in LogRocket. Explaining the decision, Helena says, “We decided that we would ditch the bootstrapped version and go for the actual real-time chat (using WebSocket), which is built so the messages and notifications about messages will be sent instantaneously, like in Facebook Messenger.”
The chat feature has evolved to be much more complex. Users can now message multiple people and groups and see the history of their past interactions.
Reflecting on this journey, Helena is grateful that she was able to apply the iterative nature of continuous discovery. “Had I decided a year ago that I needed to make a messenger, it might have taken us a long time and a lot of effort to build it without really knowing if we were going to need it and what it should actually look like. So that’s one of the wins—I didn’t make this big leap from this one tiny piece of information to a fully fledged, full-blown system of managing messages between users. We started really small and it just led us in that direction at the right time and with just enough information so we’d know how much to build.”
We started really small and continuous discovery just led us in that direction at the right time and with just enough information so we’d know how much to build. – Tweet This
How Stakeholders Have Responded to The New Way of Working
Helena has been amazed by the responses she’s received from various stakeholders. When they made the decision to switch from bootstrapping to building the full messenger, the engineer was fully on board. “Building it wasn’t that hard and I think part of the reason was that the developer also didn’t have to come up with the solution all at once. He had been iterating on it, he knew the feedback that was coming in, so he actually had time to ponder in the background and determine the best technical solution for it.”
Similarly, when presenting her plan to company leadership and the client who is investing in the development of the app, Helena says, “It was the easiest buy-in I’ve ever witnessed.” There was a lot of nodding and people saying things like, “This is brilliant!” and “This makes a lot of sense!”
Helena summarized her main discovery activities into this slide for stakeholders. They loved how easily it connected her discovery work to business outcomes.
Helena admits that her “evil plan” was to get stakeholders on board with the structure and thinking of continuous discovery so that when they’re making decisions down the line, it will be easier to remind them that they’d all agreed to work this way. “I didn’t ask for permission—I said we are doing this and these are the results, so I got them on board fairly easily,” she explains.
Reflecting on why this process was so seamless, Helena says, “With the discovery process as Teresa has set it up, there’s a narrative, a structure, and a logic. And you can use that to build a story to tell.”
With the discovery process as Teresa has set it up, there’s a narrative, a structure, and a logic. And you can use that to build a story to tell. – Tweet This
Key Learnings and Takeaways
As she considers her continuous discovery journey so far, Helena has made a few key observations.
- Continuous discovery frees up mental capacity.
Having a mental model to guide her work frees up mental space. “If you need to build something big, it takes a lot of mental work to build up the model that you need to create, it takes a lot of energy to keep it in your mind, and it takes a lot of energy to manage everything around it,” says Helena. But using the opportunity solution tree and other continuous discovery tools eases that burden. “I don’t need to keep huge models in my head, so that alleviates the mental pain.”
- Making smaller decisions is better for your product—and your own well-being.
When you make one big decision to build a feature, you tie your hands because then you have to make 100 small decisions while trying to deliver that one bigger thing. “I get anxiety over that,” says Helena. “I feel that it eats at me, so it’s not very good for mental health.” With continuous discovery, though, you’re just making a series of very small decisions while still making a big impact. “We can alleviate a lot of the everyday user pain by doing the small thing.”
- Learning to build just enough is a skill.
“It’s difficult to restrain yourself at first,” says Helena. “But eventually you learn to ask yourself, ‘How do we know that we have to build this?’” With practice, you learn to evaluate ideas and de-scope them. “Over time, it becomes easier to do less.”
It’s difficult to restrain yourself at first. But eventually you learn to ask yourself how you know you need to build something. Over time, it becomes easier to do less. – Tweet This
- It’s important to find the balance between process and the actual content of your work.
“I love the saying, ‘process is the product,’” says Helena. “Whatever process you use will give you the result. So if you don’t like the result—or the product—you should look at the process.” And continuous discovery really brings process into focus, which ultimately makes it easier to work on the content part of your job.
Helena first shared this story with the Continuous Discovery Habits community. Want to hear more stories like this one on a regular basis and get the inspiration and motivation you need to apply continuous discovery to your own work? Come join us!
