I’m not sure if I can actually share this, but I have this secret folder with screenshots of ‘things that made me love Atlassian’. Here’s one of them:

For context for our readers - this is an in-product modal shown to Atlassian employees on an internal instance of Jira Product Discovery (“JPD”).

You guys did an awesome job of ‘dogfooding’ JPD (i.e. testing and iterating with internal users before rolling out updates externally) and I was wondering if you had any cool stories that came out of this process?

(Also, this is me asking for permission to share this screenshot 😅)

10:45 AM ✓

Interestingly, in the very early days of JPD we decided NOT to dogfood because we didn't want Atlassian's way of working to muddy the waters.

Atlassian is very advanced compared to most companies, and we're a big company, so we thought it could influence us to design something that only works for sophisticated orgs.

But as the product has matured and become more flexible, we now do a lot of dogfooding. We’ve got maybe 10k Atlassian people active in JPD every month.

It’s great because when we have a bug, we typically find out about it before customers are impacted, and that’s saved us from quite a few tricky situations.

Through dogfooding, we actually found one of our “lighthouse customers” - Narmada was working in the platform team at Atlassian Guard (our identity solution).

She was struggling to get everyone to agree on priorities because it's a platform team serving multiple product teams who each have their own business objectives.

She ended up becoming one of our beta testers - and since she was internal, she was someone we could have completely open conversations with. She could share screens, we could discuss every detail, take screenshots everywhere.

We'd ask her to test stuff full of bugs, and she'd give us feedback super quickly. With internal users, we can literally throw anything at them. If they get loads of value from JPD, they're generally super motivated to help us make it better.

10:53 AM ✓

The legendary “lighthouse customer” playbook!

Not sure if you remember this, but we met in-person briefly when you’d flown over for our Agile + DevOps offsite. One thing that stuck in my memory was when you spoke to the group about your method for validating and iterating on features with a core group of 10 “lighthouse customers”.

Could you share the TLDR for how this works? I feel it’s a valuable example of a real, proven reference point for any readers working in tiger teams/products inside large orgs, wanting to incubate new ideas.

10:58 AM ✓

Ah yeah! I remember that offsite. 40 leaders in 1 conference room - chaotic but good times, haha!

The lighthouse customer thing - if there's one methodology I'll take with me everywhere, it's this one!

Here’s how it works:

The biggest challenge when building new products in big companies is that teams are often way too slow because they over-validate with quantitative data instead of qualitative insights.

Think about climate change. You can spend days reading the IPCC reports and think "wow, that’s really bad" but not actually change anything about what you do day-to-day. But if you have a 10-minute chat with 1 person who had to move countries because of floods, you'll feel compelled to help and you’ll empathise with the problem more.

Same thing in product. We'd read research reports and think "that makes sense" but it wouldn't drive urgency, it wouldn’t compel us to do something about it. But when you have one conversation with a customer who voices real pain through their words and body language - you immediately want to solve it, for that person.

So I tried an experiment: instead of building for 100s of customers from day one (based on data), what if we build for just 10 (based on conversations)?

We carefully select those 10 to make sure we’re building for our ICP, and then we really get to know them. We put them directly in front of the team, get them to share problems, try solutions, validate in real-time. We add them to Slack channels, do regular Zooms, build startup-like relationships.

We call them "lighthouse customers" because their feedback guides us when things are hazy.

For JPD, this let us make decisions incredibly fast. New mockup → send via Slack → feedback within a day. That's it. No surveys, no data science pipelines, no waiting weeks.

We embraced the bias from small sample size, because the tradeoff is worth it - it creates urgency teams need to solve real problems.

Honestly, it worked way better than any other validation method I've ever tried.

11:01 AM ✓

Love it. That’s actually a similar playbook to the one I ran with StrategyHub - many rounds of interviews and ongoing feedback for each version with a tight group.

But I feel it’s much easier as a small business. Way harder at a company the size of Atlassian.

When I was there, you were actually quite infamous among product leadership for adhering to a concrete rule: "No changes get made without customer validation."

How does this actually work in practice? Or is this more fiction than fact 😂

11:08 AM ✓

Haha - happy to say this one is true, but don’t believe the other rumours!

I've been at Atlassian long enough to know that the bigger a company grows, the more disconnected you get from the people using the product.

You start focusing more on the buyer than the user, and you feel like you have permission to just invent stuff and ship it because "we're Atlassian, it's going to work."

But we've shipped a lot of stuff at Atlassian that didn't work because of that approach.

With JPD, I'm really strict about 2 things when we consider a boulder-sized change:

1. I want to see a short video reel of different customers explaining their problem - how the pain is felt and how important it is compared to other things they struggle with. We should really “feel” the people’s pain in these videos, and experience its different facets.

2. When we design and test solutions I want to see a video reel of those same customers explaining how our solution helped them solve that problem.

It's not just "we think we solved the problem, look at this amazing screen."

It's customer problem → customer solution, explained by real customers. I keep pushing for this with the JPD PM team, Mr. Miyagi “wax on, wax off”-style.

This doesn't happen for tiny changes, but for bigger features, that's literally what I ask every PM to do. New starters get a bit frazzled when I give strong feedback on this, but the longer-standing team members are used to it now 😂

11:14 AM ✓

Fascinating. Speaking of customer problem-solving, I’ve actually used JPD myself a bunch of times for working my way through curly prioritisation scenarios. Even though I’m not a PM, I treat my newsletter like a product (I think a lot about UX, it has core JTBD etc), and I have an education product.

When I first tried out JPD, I recall 2 distinct ‘aha moments’:

1. The ‘Grouped impact’ view - ranked my tasks based on their impact towards a specific goal. Unbelievably helpful since I was struggling with prioritising across disparate contexts: “should I fix my accounting integration, or edit the vlog, or ship that sponsorship proposal, or write replies to readers, or work on my 3yr bet?”

2. The ‘Impact vs Effort’ view - a visual reframe that smacked me in the face - clearly showed what work is actually moving the needle, versus things that should just be forgotten about entirely.

Even though it wasn’t built specifically for me, or even ‘personal productivity’ use cases, it was like JPD knew what I needed to see to unblock myself.

I’m curious - what is your philosophy around ‘opinionated’ software that ‘shows the way’ to help teams mature and adopt best practices, versus flexibility and customisation?

11:18 AM ✓

Great question - this is actually super important for us strategically.

People coming to JPD need to understand within the first few seconds what the tool is for, so we need to teach them the mental model of the app, and how that applies to age-old problems they're all facing.

That's why we included views like "impact vs effort" - when we showed it to users, they'd say things like "Oh, I get it now, I can use that with my stakeholders to show that my recommendation is a high-impact quick-win".

Our philosophy is that we're not here to tell you how to do your stuff. We've come up with things that we've seen working for our customers or for us, and we keep documenting and productising those as features inside JPD.

For example we released a handbook that explains how we (JPD) use JPD in to shape the product (JPD).

But we also know most companies don't work exactly like us, or like each other. Some teams start with a project manager, some with a program manager, some with the designer or PM. Some prioritise 10yr bets, others focus on compounding cash-flow.

So what we want to provide is a collection of things we've seen work, and you create your own approach. This is why the app is so flexible, we think of it as “a canvas for product conversations”.

We’ve spent countless hours thinking through the core experience for JPD with that flexibility in mind: you can use it if you’re using the product op model, or if you manage projects with agile, or waterfall, as a product team, or a platform team, with a small team, or a large product org, etc.

Here’s how I like to frame it - there are 2 ‘products’ you create in JPD:

1. Your prioritization framework. How you frame the conversation for prioritization. What matters, what doesn’t, and why.

2. Your actual priorities. All the things you could do * your prioritization framework = your actual priorities.

Both are equally important.

We're very much on the configuration side, not convention. Every company is different, every market is different. Building physical products is different from software products, which is different from optimising a marketing website.

All have different ways of assessing priorities, but all need to be supported by the tool.

11:22 AM ✓

What would you say is the most counterintuitive thing you've learned through building JPD?

11:26 AM ✓

Well when we started JPD, we had strong opinions like "time-based roadmaps are bad, and we're never going to support them." Then we got beaten into submission by the sheer volume of feedback!

That's when we started coming down from our high horse and understanding that while problems can manifest in different trends, the underlying issues are age-old and always the same.

We realized we can have opinions and state them, but people may see them as aspirational. They'll still do things that are completely contrary to what those ‘best practice’ ways of working prescribe - and that's okay, because that's what works in their context, and they might change their approach gradually over time.

It's very important to have a strong opinion, but it's equally important that people can use your software in ways that don't agree with those opinions.

After five years working on it, I've realized it's almost impossible to create a great product that is super opinionated with no flexibility!

I'm letting go of a lot of aspirational beliefs that aren't necessarily always applicable. Ways of working are context-dependent - they're not universal truths. Beliefs are great, but our job as PMs is to convert them from beliefs to validated assumptions, and change our mind based on what we learn.

There's this tendency in product to think we know everything better than everyone else. But there are always companies that have been successful for decades without aligning to your beliefs.

I guess you could call this one a hard-fought discovery over five years, rather than a single realization!

11:30 AM ✓

This has been brilliant - thanks for doing this!

Any final thoughts for readers who might be working with similar challenges inside large companies?

11:33 AM ✓

The main thing is: if you're a PM feeling like you have no agency and you're constantly being told no by leadership, there's a way to solve that!

It's about framing conversations better and transforming oppositional forces into collaborators.

You need to take people along with you on the journey so you're not alone - you're working together on shaping the product.

If you can get good at that, you can claim more autonomy and actually get to do product work instead of just being told what to build.

That’s why we’re creating JPD, to help you with that!

11:38 AM ✓

Perfect way to end it. Thanks again! 🙌

11:42 AM ✓

Cheers 🚀 Thanks for having me!

11:44 AM ✓