By Teresa Torres · producttalk.org · @ttorres on X · LinkedIn
Teresa Torres profiles product manager Helena Jeret-Mäe at Singularity Creations, who moved from building speculative features on request to a continuous discovery practice. Early on, she built an unused field a customer hypothetically wanted, which later pushed her to structure requests with an opportunity solution tree. Her team then broke a big idea, letting coaches nudge lagging coachees, into small bootstrapped iterations that used notifications disguised as messages, LogRocket session observation, and customer conversations. Only once real usage showed the need did they commit to a real-time chat system. The story shows how small validated steps reduce risk, mental load, and stakeholder friction.
01Key takeaways
- Anchor every request to a clear desired outcome so saying no becomes easier to justify.
- Use opportunity solution trees to make product thinking visible to stakeholders.
- Test small, cheap versions of an idea using existing tools before committing to a full build.
- Let usage data and customer conversations decide when a feature has earned a bigger investment.
- Making many small decisions reduces mental load and anxiety compared with one large, risky bet.
- Process shapes outcomes, so improving your discovery process is often the fastest route to better products.
02Key sections
- Saying no with a clear outcome
- Saying no to requests is central to focus, and a desired outcome plus an opportunity solution tree makes those refusals easier to explain. Visualizing the thinking helps stakeholders see why some requests wait.
- The unused field lesson
- Helena built a low-effort field a customer hypothetically wanted, and it was never used. This mistake showed her the value of evaluating requests against real use cases.
- Breaking a big problem into small bets
- Rather than building a full messaging system, the team tested a text box via existing notifications, then added group messaging after observing copy-paste behavior. Each iteration was guided by usage data and customer feedback.
- Deciding when to build the real thing
- Customer feedback about forgotten message history revealed the need for a proper system, and the team moved to real-time chat only once the evidence justified it. Incremental learning kept the build appropriately scoped.
- Stakeholder buy-in and well-being
- Shared discovery structure and a clear narrative earned easy buy-in from engineering, leadership, and the client. Small decisions also reduced Helena's anxiety compared with one large, risky bet.
03From the post
“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”
04Frameworks mentioned
Summary and takeaways written by PM Atlas; quotes are short excerpts. © the original author.