Building Jira Product Discovery from idea to one of Atlassian's most loved products
For the past 4 years I've been leading the design of Jira Product Discovery. We started in an internal Atlassian startup incubator and grew to serve over 25,000 customers.
A home for the messy work before development begins
Product teams live in a gap. Engineering has Jira. Sales has a CRM. But the work of figuring out what to build and why — collecting customer insights, weighing trade-offs, aligning stakeholders around a roadmap — that work lived in scattered spreadsheets, slide decks, and Confluence pages nobody could find.
Jira Product Discovery was built to close that gap. It gives product managers a dedicated space to capture ideas, enrich them with customer evidence, prioritize with custom frameworks, and share roadmaps that keep everyone from leadership to engineering aligned — all natively connected to Jira Software so ideas flow into delivery.
Head of Design
I joined to lead a design team of 1 when entire the team was just a dozen people. The "pirate" culture of this specific area allowed me to approach this how I wanted. And how I wanted was hands-on, working on the product every, working with product, engineering and marketing leads to define the product strategy, the conceptual model, the go-to-market strategy.
Over four years I grew the design function from a single designer to a team that could support a product serving tens of thousands of customers, all while keeping the scrappy, opinionated energy that made the early days productive.
From incubator sketch to 25,000 paying teams
Finding the shape of the problem
Small team, big ambiguity. We spent the early months talking to product managers across industries to understand what PMs actually struggle with. We found some pattenrs: Product Managers struggling to keep everyone informed, always unsure if they're investing in the right areas, always possesing more ideas than they have the resources to impement.
But we also found there's no one way to do Product ~Management: everyone is tracking different things, towards different goals using different methodologies - this led us to a very flexible conceptual model that we could keep simple yet powerful.
Co-creating with lighthouse customers
We on-boarded a handful of early adopters and designed alongside them. ANd because they're Product Managers that also ship software they are very good at articulating what they need,
Real customers, real work, real use. This wasn't "validate our mockups" — it was givin people ver yearly acces to features, seeing where they work and where they break, iterating... again and again.
The real validation is whe ncustomers take out their credit cards and are happy to pay for the product.
All through beta we asked customers every moneht "how dissapointed would you be if we stopped supporting this product". This metric served us well but when we made the product Generally Available the best confirmation came in the form of our firs dollar. We suddenly had one of the fastest growing, most loved Atlassian aprodcuts: the pressure to keep this trajectory was on!
Scaling from teams to organizations
Premium introduced cross-team roadmaps, hierarchies, and governance features for larger product organizations. The design challenge shifted: how do you add organizational complexity without breaking the simplicity that made the Standard product loved? Turns out the aswer, in most cases, was to stick to our clear and simple mental mdel: all our entries are stored as a set of field values, and visualised in different types of views.
25,000 paying customers, growing as fast as ever
From less 500 free early users to 25,000 paying teams. 125% YoY growth. Consistently one of Atlassian's highest-NPS products. The team has grown but the principles haven't changed. And the weekly design review is still were the most impactful conversations happen.
Four principles that kept a small team punching above its weight
We operated inside a large enterprise company but with startup constraints — small headcount, high expectations, and a copetitors that started a dacade earlier. These are the design and product principles that made the difference:
Pragmatic prioritization
We couldn't build everything, so we had to be intentional. Every feature earned its place by solving a real customer need — not a theoretical use case or a competitive checklist.
Design with users, not for them
Especially in the early days, our best design decisions came from deep conversations with customers, understanding the real context of where work happens and iterating with customers. We didn't just test — we co-created using a good - better - best model.
Protect the core
We defined a clear conceptual structure early — the app is just a database of work items. Fields hold the definitions of the infinite possible facets of the work. Views allow you to visualise all of these ideas. We've learned to build almost any feature for any job on top of this model.
Balance velocity and quality
Shipping fast is important, but not at the cost of experience quality. We found a rhythm: move quickly on the first version (good), then immediately invest in polish and refinement before moving on to the next thing (better). Let customers really test the limits of what we built and with enough feedback iterate one more time (best).
Scaling inside a large enterprise without losing your focus
Building a new product inside Atlassian meant navigating real tension. On one hand, we had the resources, distribution, and brand of one of the world's biggest software companies. On the other, we were working inside an ecosystem with strong opinions about how products should look, feel, and integrate.
The design challenge was constant: how do you make something that feels native to the Atlassian platform while being opinionated enough to actually solve a specific problem well? A generic tool wouldn't have worked. Product managers needed something that understood their world — not just another project management board with different labels.
What I learned leading design through zero-to-one and beyond
Four years leading this product taught me that the most impactful design work often looks like strategy. Deciding what the product isn't. Defining a mental model that can absorb complexity without collapsing.
I also learned what it takes to scale a design team through different phases of a product's life. The skills you need in a scrappy incubator team of one are different from what you need when you're supporting a product with tens of thousands of users. The trick is knowing when to shift.
This was, and remains, one of the most rewarding products I've worked on — not just because of the numbers, but because we built something that product people genuinely love using every day.