🎥 How to uplevel your product discovery practice webinar - recording + Q&A
Hi all!
Thank you to everyone who joined our webinar "How to uplevel your product discovery practice with Jira Product Discovery"! We were so pleased you attended and thank you for your excellent questions!
You can watch the recording on demand here: https://www.atlassian.com/webinars/software/how-to-uplevel-your-product-discovery-practice-with-jira-product-discovery, and below you will find the top 19 most frequently asked questions during the session! If you have any others, please post them in the comments section below.👇
Thanks!
Chris
Top 18 FAQ
1. What are “boulders”? How can we create a hierarchy of boulders and 'smaller' Ideas within JPD?
This is the hierarchy the JPD team uses:
-
Themes = logical grouping of boulders
-
Boulders = something an entire team can own and focus on for 6+ months to reach specific goals
-
Focus areas = logical grouping of ideas in a boulder
-
Ideas = individual projects/initiatives that can contribute to the success of the boulder, large or small
-
-
-
2. Are your teams/squads full stack, so they include FE and BE engineers? Do you work in sprints?
We have both full stack and FE/BE engineers. More generally, we value the craft of “product engineering,” meaning engineers who are very good at talking about user problems and solutions vs. simply implementing things. These engineers are often the ones doing a lot of the work that product managers typically do in other companies, including making decisions or recommendations about UX.
3. I just started a PM role at a company that’s building a product starting from 0. What’s the best way to start my product discovery practice from scratch? How does this change when I start scaling up?
We did a talk back in February about this specific topic: https://www.youtube.com/watch?v=GRfXkt78avE.
4. Can JPD be used to manage hardware development?
Of course! You can use Jira Product Discovery to capture and prioritize ideas, regardless of the type of product you’re creating. Your prioritization practices might vary, and JPD is most useful when your delivery piece is also happening in Jira Software – but we encourage users from all backgrounds to try and see if Jira Product Discovery could work for their specific use case.
5. How do you do discovery without a triad? I’m a team of one.
You can absolutely do discovery as a team of one – it just means more work! 🙂 Reach out to your existing customers and ask them what their pain points are. For each pain, ask them what makes it a pain – get more details. If you do not have customers yet, go chase your ideal customer profile on LinkedIn by messaging people directly and ask them if they would pay for your product/idea. From there, keep doing research until you have a good understanding of what the need is and how you might help.
6. What percentage of your time do you spend on product discovery versus delivery? How much time do your PMs spend keeping up JPD?
It’s hard to quantify. We don’t think of it as discovery VERSUS delivery. A product discovery practice is about validating bets constantly based on learnings from talking with customers, the data, etc. Sometimes we ship something to test a concept with a small number of customers and validate an idea for example. But generally speaking it depends on the phase we’re in. Sometimes a PM in our team would spend 50% of their time on ideas in the “Wonder” stage - talking with customers, unpacking the problem space, reviewing competitors - or the “Explore” stage - designing solutions, testing solutions with customers. Sometimes we’re all in on execution on one of the boulders, after the solution’s been validated, to get it out the door. We spend on average 30 min - 1 hour in JPD each day.
7. How does your sales team interact with your roadmap?
At most organizations, sales teams are regularly pinging product teams asking them for updates on when a feature is going to land. With JPD, sales teams can now self-serve this information – and that’s how it works at Atlassian. The go in and leave comments on ideas, indicate which customers would be interested, provide reactions to ideas. It helps them feel like part of the process and gives the product team valuable insight from the rest of the organization.
8. How do you choose the ideas that are even worth validating?
We get hundreds of pieces of feedback from users each week (inbound feedback, user interviews, etc.) - so choosing ideas worth validating isn’t really a problem for us, our problem is more “what of the 50 things worth exploring should we focus on next? Should we stop something to focus on something more important?”
I think if you have a problem like this, the first thing to fix is to get in a situation where you are talking to people (customers, users, prospects, buyers) super regularly (5+ times a week). The opportunities and problems worth focusing time on will come up regularly.
9. How do you incentivize your users to work with you?
We’re pretty lucky in that recruiting people to talk to has never really been a problem for us: people spend so much time in Jira, they’re investing in making improvements, so they’re keen to talk to us to explain how and why.
However, there are tactics that work better than others (we use Calendly to get people to book time – it’s very good!):
-
Showing a banner in-app “want to talk to one of our PMs? click here to book time.” (This sometimes works but it’s usually not personal enough.)
-
Sending an email saying “Hi Janine, I’ve noticed you’ve been using JPD a lot over the past couple of weeks, would you like to chat to discuss your context and how we can make it better for you? Click here to book time.” (This works really well!)
-
Creating a post with a concept in community.atlassian.com with a link to book time to discuss it. (This also works well.)
-
Recruiting people who are not users is generally harder. We’ve used userinterviews.com for that, and gave $100-$200 vouchers, but then screening people is really important to make sure the conversation is productive.
10. How have you persuaded leadership to ditch timeline views?
Mostly by focusing the conversation on demonstrating we’re moving fast and learning fast – e.g. when we started JPD the mandate was “you have 3 months to ship an MVP”. We knew that wouldn’t be doable, but said okay anyway. 🙂 So we started sharing 3 minute Loom demos to them every week, and a monthly leadership update that included learnings from speaking with users and customers, what worked/didn’t work - it showed clear progress, every week. Then when the 3 months came people didn’t care that much about the deadline anymore – the feedback was: you’re moving fast, you’re clearly focusing on the right things, you have amazing user insights! Changing their perception so they understand that they don’t need to worry about managing the project, but instead can sit back and enjoy the insights, new features, etc. is very important. But you can only start reframing the conversation if they trust you. And for that you need to keep delivering on your promise (starting with quick wins and tackling progressively bigger things), and teach them new things. And these new things come from user insights, competitive insights, learnings from testing concepts, etc.
11. How do you measure impact after the launch of a new feature?
It’s highly dependent on what the feature is trying to achieve. But in general, it’s a mix of qualitative and quantitative:
-
Qualitative: we built a feature because people talked to us about a problem. We go back and ask if it did solve it for them, and if so how. If we’re happy about the answer then good. If not, then we iterate. We also look at user feedback and support tickets to understand if the feature works as intended. If we have an influx of tickets because of it, we need to fix that.
-
Quantitative: we look at engagement metrics (e.g. number of customers/users that should be using it that are actually using it). We often need to iterate there: because the feature might be good, but not discoverable (as in: the users that find the feature find it valuable, but too few users do - so we need to rethink where it is in the UI)
12. Do you have a one pager template?
We don’t have any templates yet (we’ll start working on it!), but here is a screenshot of the one pager template that you can replicate yourself in Confluence!
13. How do you convince the organization to invest in product discovery when the business demands quarterly financial results? Failure and spending time exploring are not always acceptable.
You can’t tell a soccer team: “just go and score points and win all games”. The method (training, etc.) is important. Product discovery is our method to play well and score points. Financial results are the outcome. Play the game well and the score will take care of itself.
That’s all good in theory, in practice we know that some company cultures make it harder for you to do that. To turn this around, it’s a good idea to focus on PM being the trusted partner for business, that can help them get to their goals. And to do that you have to build trust: commit to things, start with a few quick wins deliver on these commitments, tick these boxes, start teaching them things they don’t know (about the market, the customers, the data). They’ll trust you more and listen to you more.
14. At what point do you train other internal teams (sales, support, marketing, etc) on how to use JPD?
Most teams start with first adopting JPD in the product team, then expand to the core team (engineering, designers) and when that’s good, then the next step is usually to do a pilot with a small number of stakeholders (sales, support, leadership). After they’re done with that, they roll out to everyone. Basically step by step. But first you need to be very clear where you want everyone to participate in the process, and make these expectations clear. That’s why it’s a good idea to start with a pilot with a few champions from sales/support/marketing, who are sympathetic to the challenges you have as a PM, and want to solve this collaboration.
We do have many companies for which 50-80% of the company is in JPD every month.
15. How do you defuse the ask from every executive, sales person, and customer about when feature X is going to ship? How do you set them up for success when you just say “later”?
It’s all about giving them perspective and a bit of understanding of how product works – a few ideas:
-
Put them in your shoes: walk them through the competing priorities you’re trying to juggle, and ask them how they’d approach it.
-
Get them to make the trade-offs: explain that if they want X to go there faster, they need to deprioritize something else: which one should it be?
-
Demonstrate progress regularly: e.g. walk them through the progress you did on X for the past two weeks or one month. Or, what we do, is we share a 3 minute Loom every week in a demo to demonstrate progress, so they see we’re focusing on the right things and being methodical/intentional about it.
-
It’s a good idea to also be clear about the stage you’re in. e.g. saying “it should land in the second half of the year, or Q3, or November” - these all can explain the level of certainty you have at this stage.
16. When it is a PM's turn to be "on support", what does that look like? Is it for the entire week or just several hours a day for a week?
It’s usually about an hour a day for the week – and it is an hour well invested as we identify new users to talk to this way. It involves PMs going through user feedback tickets, helping support teams answer questions, responding to questions from internal users and helping users in the Community.
17. How do you define which customers fall into the 10, 100, and 1,000 rollout buckets?
It depends on the feature and what we’re trying to learn.
-
The core group of 10 companies is the most important, these are the true lighthouse users: face the problem the most, great communicators, have tried many different ways to solve them, are ready to work with you on early solutions, etc.
-
The 100 group: we usually look at how they explain the problem they’re trying to solve (we ask them to fill a form clearly explaining why they need it), then also looking at how they use the app. e.g. if they’re an early evaluator, it won’t work, but if they’ve been using it for a while and are committed, it would. Things like that.
-
The 1,000 group: it’s a simple percentage-based rollout of the feature (we use LaunchDarkly to manage feature flags.)
18. As a manager of PMs, how do you keep track of what your team is working on?
The best thing to do is enable your PMs to work autonomously: sit down with them and clearly agree on goals (if you can’t frame them, then that’s something that needs to be solved first), coach them where they need help (e.g. prioritization, user interview skills), and do a weekly sync/monthly review with them. In particular, it’s good to identify what’s blocking them so you can clear a path (e.g. they can’t secure a commitment from another team for a dependency, etc.).
Was this helpful?
Thanks!
Chris Hall
16 comments