Community Wisdom: Prioritizing your roadmap, getting better at customer discovery, working effectively with your designer, testing for interest with a fake button, how to resign, and much more
Community issue 63
👋 Hello and welcome to this week’s edition of ✨ Community Wisdom ✨ — a subscriber-only email, delivered every Friday morning, highlighting the most helpful conversations in our private Slack community. As always, a big thank you to Kiyani for curating.
💥 Top threads this week
1. Prioritizing your roadmap
Q: I'd love help on the post-brainstorm grooming process. We had a large team brainstorm containing 100+ product ideas (and also created a Jira board for idea collection moving forward). I'm unclear of how to go from where I am today (lots of ideas) to where I want to go, which is a full 2022 product roadmap. A lot of the ideas could be great but would need more testing to determine whether we should build them or not. For context, we're a seed stage startup so there are a lot more unknowns than a late stage company. Would love any help! ↗️
– Deirdre Clute
Scott: Hey Deirdre, sounds like you have a prioritization problem.
First, your product vision and strategy should act as a filter here. While you might have lots of ideas as a team, not every idea is likely applicable to meet your future vision.
Once you've reviewed with that in mind, I’d ask three questions:
is the opportunity big enough? Are there enough people with this need?
is the problem painful enough (importance x frequency = value)
is the existing product good enough?
This should help narrow your list.
If you're interested in some more reading on prioritization check out our ebook on the topic: The Essential Guide to Prioritization.
As far as balancing a long-term roadmap with the flexibility to change, that's tied to the outcomes you want to meet and the problems you're trying to solve. Getting the team focused on the outcome, and leaving them the room to conduct continuous discovery and experiments will keep things focused more on your product and the goals and needs of your customers.
Sandeep: +1 to Scott. Vision and strategy should filter ideas. I would also think about breaking the roadmap down to smaller feedback loops. ie., quarterly. This roadmap could be a combination of product MVPs, manual testing with Figmas, research/user surveys, etc.,
A year seems like too long to plan the roadmap at a seed-stage startup.
Andrea Saez: Hi @Deirdre Clute - to echo what everyone else has said, start with your vision, then objectives, then look at larger initiatives to solve problems. That in itself will let you know which ideas align with your initiatives/outcomes.
I’d also warn against trying to create a yearly roadmap. Roadmaps are much higher level than that - think now/next/later, where:
Now = stuff you currently have committed resources to
Next = things that are in discovery/entering discovery
Later = problems you don’t understand yet, but are within your scope of problems to potentially solve
Remember the roadmap is not a static document, it’s dynamic and will change with research/discovery/market trends, etc. You can supplement details with a release plan, but they are two very different documents that will communicate different stages of your progress.
If you’re looking for how to start prioritizing on the roadmap level - there are various techniques. I personally really like the opportunity solution tree by Teresa Torres.
Josh: Y'all have no idea how happy it all makes me that everyone's feedback is "have a clear vision and prioritization comes easily."
The only thing I'd add is: this early on you also want to make sure you know your most important metrics: trial => signup conversion rate? A number of API calls made per day? PMF survey?
Andrea Saez: Yes, but also remember metrics are tied to outcomes, and OKRs/KPIs shouldn’t just exist to exist 😜 but that may be another conversation.
2. Getting better at customer discovery
Q: In an attempt to be better at customer discovery on customer calls, I have always frozen after the first round of questions and have not been able to dig deeper into the actual customer problem which will help understand the pain in a deeper way . I have read and re-read the “Mom Test” which has helped a bit, but are there other things that will help improve this process that has worked for you. Any recommendations on what I can do to improve this? Thanks in advance. ↗️
– Karthik Neelakantan
Jordyn Bonds: @Karthik Neelakantan What do you think is the cause of your freezing? E.g. If you're just not great at thinking of questions on the spot, maybe take some time to reflect before the next call on what you’ve heard from customers so far and what you wished you’d thought to ask them during those previous calls. Bring that with you to the next call and see if any of those issues come up – then you’ve got a chance to ask!
Bob Gilbreath: The easiest and most effective thing is to ask “Why?” I can be a little uncomfortable but it comes from a spirit of genuine curiosity and people are usually happy to keep digging. This also means going off your question script and following people down the Why rabbit hole. Here’s one of many sources of the Five Whys.
Janani: This is an interesting question. And I love that @Bob Gilbreath suggests asking why.
Are you perhaps expecting the answers you want to hear? And are you already looking to hear about the problems you think exist?
Typically during user interviews, I always have a set of questions I want to be answered. Starts with:
What value do you see in our product? Why do you use it? The answers to the why can lead to more whys. The more the whys the deeper the conversation. It would lead you elsewhere to what you thought were the problems, but that's ok. You are not actively solutions here. You are identifying the problems.
How often do you use it?
What would make you use our product more? (This is when they talk about abstract problems they have with our product or how we are not able to help them achieve their goals).
What other products in the similar space do you use? What do you like about them?
If you already have a product, ask them to walk you through what they would regularly do. Coz people do different things than they say they do.
Lucinda Musa: To provide a different perspective, I actually don’t like asking why explicitly. That’s because humans are very bad at giving the real reasons behind their behavior. You can see more on this TED talk: Don't Listen To Your Customers - Do This Instead
As for ways to improve your process for digging deeper. Here are some things that have worked for me.
Listen. Do not take notes. Let someone else do that, or go back on the recording. Listening to what they say is the absolute best way to find things to dive deeper into.
Don’t fly through questions. Leave space in between to dive deeper. For example, have 5 questions. But after question 1, ask for follow-ups.
Here are some go-to’s I have for follow-ups:
Define lingo - “You mentioned X term. What is that?”
Go deeper on an ambiguous term, by repeating the unclear phrase - “This process is manual.” “Manual??” (it’s a tool called “mirroring” to get them to talk more)
Ask for examples - “You mentioned that the process for updating this data is difficult. Tell me about the most recent update you did.”
The show, don’t tell - “You mentioned the table on X page is confusing. Can you share your screen and show me? I’d like to see how you do it.”
Karthik Neelakantan: Thank you all for the responses! I am going to try to incorporate some of these and come back to this thread and post how I have potentially improved. Thank you once again.
3. Working effectively with your designer
Q: As a PM - how do you leave enough freedom for designers while setting tight enough boundaries to move in the right direction quickly?
Too often I find myself changing design decisions because their decisions are either not aligned with our product vision and principles (e.g. solving for a different use case and explaining UI rather than making it intuitive) or are not considering known user feedback. Obviously, this creates frustration, more forth-and-back, and slows progress down. How do you solve this? ↗️
Maurice Eisenmann: How much information do you give your designers? Do you stick to writing a PRD and then leave it up to them to bring your document to life or do you wireframe your ideas out?