How we built JPD with lighthouse users (Part 2 of 3)

[#1]

This article is the second instalment of a what will hopefully be a content collection aimed at sharing the product management practices that have enabled Atlassian to be a category leader.

In this second article, we will be focusing on how we selected lighthouse users to collaborate with and why.

These are the very practices that have led Jira Product Discovery to be the fastest growing product at Atlassian.

You can find the first part of this article here.

Lighthouse users building Jira Product Discovery

Meet the Jira Product Discovery (JPD team)

During the Wonder stage, Designers and Engineers from the JPD team spend a large part of their time with users on calls, support and research.

This means that when they hear directly from customers about their circumstances and their struggles, they can better empathise with them and they really want to help.

If you present the team with a persona or an Ideal Customer Profile, it is understandable if they can’t relate. Most times, a persona or ICP does not feel real.

How to identify lighthouse users?

There are 2 aspects that matter in identifying your lighthouse users

• Are you learning enough from your interactions with them?

• What are the criteria you’re looking for in choosing them?

Over time, the idea is that you keep learning about who you’re building for, and find people you believe are representative of that.

We did not get this right the first time round. Quite the opposite in fact.

We conducted 2 rounds of research to uncover these dimensions so we could be confident in knowing who we were exploring these opportunities for.

The research we conducted showed us that we wanted to target PMs with the following profile:

• Is someone who has a level of autonomy to make decisions, but aren’t so autonomous they don’t need to provide a rationale.

• They are not in large teams of PM (as these PMs have needs that Polaris doesn’t currently support)

• and their development teams are currently using Jira Software.

✱ Polaris was the codename for JPD during the earlier stage of the product development cycle.

After a bunch of conversations we needed to rationalise this and here’s what we came up with.

Universal criteria when choosing Lighthouse users

✔ They are very clear communicators

✔ They are in your target customer segment

You might not be 100% clear on what your target customer segment looks like at first and that’s OK. It is an iterative process where at any point you want to have a definition of what that target segment is so you can keep testing it in all the conversations you’re having with users.

✔ They feel the pain very strongly for the problems we’re trying to solve

They help us understand the problem better and identify other challenges.

✔ They are constantly trying to find new ways to solve this pain

And have not been successful yet.

✔ They are not using a competing app

And so we are not anchoring on that (e.g. comparing solutions)

✔ They fit with the product vision

Their context is aligned with the vision for how this product solves for the identified problem space and how it might evolve.
E.g. if JPD is a canvas for product conversations, then our users are aligned with this.
So it would not have been helpful to choose a user who only believed in fixed timelines, scopes and deadlines as a lighthouse user.

✔ They are happy to use a very early stage product or feature

And share their feedback and spar on solutions.

Recruiting lighthouse users

Here are a few tips to hire your lighthouse users

• Create a way for people to get in touch with you

  • This could be through a landing page where you surface your lighthouse user program or via an in-app survey.

• Use a form with a few questions that will help you triage requests and understand your customers and their problems. You can do this by including a required text field in your form asking them to describe the nature of the problem they are faced with.

• Qualify your leads

  • You might be wondering “how am I going to deal with an important influx of requests?”. That’s a good problem to have. Use the information collected through the form to qualify your leads and get a prioritised view of who you’d like to engage with based on the problem you’re trying to solve.

• Send them a scheduling link

  • If you are curious to know more about a potential customer, time to meet them.
    Send them a scheduling link so they can easily book time in your calendar.
    In the JPD team, we send a Calendly link so customers can book time with us once we’ve qualified them.

10 lighthouse users are enough

While there isn’t a hard rule that says 10 is enough, our experience shows that 10 lighthouse users are enough. Here’s why:

• You want a group that’s representative of the people/market you’re trying to address

• You are not looking for statistical significance but rather causal mechanisms

---

You can find the first part of this article here.

If you've enjoyed this article, please let us know by liking 👍 this post.

Part 3 of this 3-part series will showcase examples of real lighthouse users in building JPD, the collaboration setup between the users and the JPD team and key takeaways from this series. 

👁️ Watch this space if you want to learn more about how we do product in the JPD team.

[Olivia Voils]

Hello @Axel Sooriah, thanks for this part 2 article. You've nicely included some logistical tips for recruiting lighthouse users.

I'm more curious about how to incentivize or motivate users to join or participate. And this is coming from the perspective of a much smaller company than Atlassian. One concern is about avoiding overuse of ideal lighthouse users if we're not able to identify and maintain a deep enoough pool.

I'd love to hear about your experience or thoughts on this topic.

[Axel Sooriah]

Hey @Olivia Voils,

thanks for reaching out.

This is a common question and I think it really depends on the context (as with everything else in product 😅).

I found that

• when you need to recruit people for "tasks" e.g. when testing a prototype, it's common practice to incentivise them and also some people now just expect it. It doesn't mean they wouldn't do it with no incentive but it helps.
• when doing user interviews, it really depends on who you are targeting and how difficult it is to recruit participants e.g. in our case, lighthouse users are willing to invest the time (often without the need or request for an incentive) because they find value in solving the problem together with us.

That said, over the past 10 years working across small and large companies, in B2B and B2C, there were only very few cases where an incentive was truly necessary to land participants and these were cases where the participants were truly scarce (think a very small population of doctors specialising in a particular branch of medicine) or where they were extremely busy and needed to justify the time spent. In these cases, incentives can be a sizeable budget. 

Feel free to connect on LinkedIn if you want to chat about it.