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

[#1]

This article is the first 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.

This first article, a 3-part series, we will be focusing on how the Jira Product Discovery team has build the product with lighthouse users.

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

4 stages of an idea

Before we get into the weeds about lighthouse users, here’s some context about our framework for product development.

It is a shared way of working for launching and improving products and services that helps maximize the chances of product success. It is a pattern for how Atlassian creates products and services and is based on principles that help teams make decisions about how they work by aligning expectations in what is needed for impactful outcomes.

These 4 stages are Wonder, Explore, Make, and Impact.

• The 'Wonder' stage is about gaining a deeper understanding of the problem space and what success looks like.

• The ‘Explore' stage is about testing and validating solutions to the problems we’ve identified. Including in some cases creating a first iteration (it’s about validating a solution is the right one - sometimes it works with Figma, sometimes people need to use a thing before they can be confident it solves their problem).

• The 'Make' stage is about iterating on the solution until it satisfies the needs of enough customers and users. We ensure the solution works for 10 customers, then a 100 customers and then onto a 1000 customers. At each stage we are solving for different challenges.

• Finally, the 'Impact' stage is about measuring results and improving the solution until satisfied with the outcomes.

→ Then comes the ‘Scale' stage which is about making the product generally available across potentially hundreds of thousands of customers.

Why should you care?

I like to think of lighthouse users as your superpower when developing a new product or feature. They basically offer a stream of invaluable insights, quickly and continuously that help with your product decisions and confidence that you’re building the right solution to the identified problem.

And the most important thing is that it’s not at all that complex. Far from it.

At Atlassian, lighthouse users are one of the main reasons why we’ve been successful launching Jira Product Discovery.

What is a lighthouse user?

There are 2 schools of thought when it comes to informing product decisions through research:

1. Mitigating bias
   Here, the general approach is to conduct a research project with a start and end date, a fixed number of participants and a big report with findings that often ends up collecting digital dust on a Google Drive.
   
   

2. Embracing messiness
   We make decisions based on gut-feeling (even when they’re informed by data) and it’s as biased a process as we are human.
   Building for humans is messy, we get that and we fully embrace it. We know that we won’t always get it right (for instance finding the right lighthouse users can be tricky) but our experience shows that it eventually pays off.
   
   

Spoiler alert: we chose the latter.

It is our belief that building a successful product requires working closely with a small, dedicated group of users who truly understand the problem the product aims to solve. These special users, known as "lighthouse users," are usually involved right from the start of product development. They play a big role in guiding the direction of the product, ensuring it meets the right needs.

In our experience, working with these lighthouse users works better than trying to please thousands of users all at once or relying on vague ideas of who our users might be. Brought in early, these users take an active part in the development process and shine a light on the direction the product should follow.

Why turn to lighthouse users? 

• Learn and execute 10x faster
  It requires deep customer understanding, deep focus and often, a willingness to start small and think differently about scaling and evolving the product or service offering.
  
  

• Escape analysis paralysis
  Some teams experience “analysis paralysis” by trying to validate everything with many users. It’s often not necessary - a discussion with a small number of users, if they’re the right ones, is enough.
  
  

• Get rich contextual insights, otherwise impossible
  Building rapport with someone takes time but that’s where you learn more about their motivations, problems and how you can help. For this it’s often more impactful to have multiple conversations with someone than a single conversation with many people.
  
  

• Drive team motivation and agency
  If you want your team to solve a user problem, introduce your team to a real user. It will drive their motivation, sense of urgency and agency. They’ll want to solve problems for one person they met over abstract user personas.

When to turn to lighthouse users?

You already have a general idea of the problem space you’re exploring

Before going to lighthouse users, we conducted exploratory research with 50 participants to get a better idea of the prevalence of the problem as well as its intensity.

If it works for them, it’ll work for others who are faced with same/similar challenges

Building for lighthouse users is effectively a small group of users as a proxy to a potential, larger population. We do this intentionally so we can have high confidence in our decision-making as quickly as possible.

Finding the right lighthouse users is critical to the business because
→ they might evolve over time
→ it has consequences on your positioning

You need a balanced group which is representative of the market you’re trying to serve.

OK but what does it really mean?

If you are serious about moving fast, you do not want Product Managers (PMs) to be making all the decisions, with the rest of the team behind them.

Why?
Because they are a single person and can often be the bottle neck in these contexts. Instead, we want to bring in other team members e.g. Designers and Engineers, who are better at solving some of the hard problems users are faced with.

What it really means is that you can leverage the collective intelligence of as many more people there are in the team who behave as PMs.

---

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

Part 2 of this 3-part series showcases the journey of the Jira Product Discovery team working with lighthouse users. 

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

[Tatiana Chernogorova]

This sounds like a great idea: creating a product with immediate feedback from a very small group of trusted users. I was (and still am) lucky enough to have a bit of similar experience when designing functionality for internal systems.

The difficulties begin when you are designing new products  by that will be used existing external customers of your company. There is a misconception even among not that old colleagues that if you are asking customers for cooperation, you immediately loose your reputation as an expert and that will harm customer relationships. And misconceptions are a very hard thing to overcome, even though you may know how badly outdated they are.