The Adaptavist Library was envisioned as a repository where users could find ready-made scripts for ScriptRunner — Adaptavist's flagship Jira, Confluence, and Bitbucket plugin that lets people write Groovy scripts to automate tasks in Atlassian tools. Instead of writing scripts from scratch, users could come to the Library, find what they needed, and eventually install scripts directly from inside ScriptRunner itself. But after three product managers cycled through without landing on a clear vision, the CEO came to me with a direct mandate: figure out whether to kill the Library or make something of it. I used stakeholder interviews, systems thinking, and Wardley Mapping to develop a strategy that the entire organization rallied behind — and the Library became a success.
Inheriting a Product After Three PMs Bailed
The Adaptavist Library had a straightforward premise: ScriptRunner users shouldn't have to write every Groovy script from scratch. The Library would be a curated repository of scripts — automations for Jira workflows, Confluence management, Bitbucket hooks — that people could grab and use. The longer-term vision was even more compelling: integrate the Library directly into ScriptRunner so users could browse and install scripts without ever leaving the app.
The problem was that none of the three product managers who'd owned the Library had been able to turn that premise into a coherent product. Each one brought a different angle, started work in a different direction, and then moved on before anything solidified. The result was a lot of half-finished initiatives, an overly complex architecture, and a team that had lost confidence that anyone would stick around long enough to give them real direction.
That's when the CEO came to me. His ask was blunt: take a hard look at the Library and decide whether it was worth saving or whether they should cut their losses and kill it. After three PMs had failed to crack it, that was a real possibility on the table.
Why a Good Idea Kept Stalling
The Library's concept was sound — ScriptRunner had a massive user base, and those users were constantly solving similar problems independently. A shared script repository was an obvious win. But good ideas don't ship themselves, and the Library had accumulated the symptoms of prolonged strategic drift.
There was too much complexity. Each PM had added their own layer of ambition without cleaning up what came before. Feature requests piled up from multiple stakeholders with no framework for prioritizing them. The team had no clear sense of whether the Library was a content play, a product extension, a community platform, or something else entirely. Every sprint felt equally important and equally arbitrary.
Compounding the problem, the lack of good product management had led to a direction where engineers were custom-building everything in-house. When I did the initial Wardley Map, I found that almost every piece of the Library was sitting in the far-left genesis column – the team was trying to build the entire stack from scratch. They were reinventing the wheel over and over again, spending so much time building and maintaining infrastructure that there was no time left to actually create scripts or build the functionality users needed to submit their own.
The team was demoralized. The most senior engineer – the person who had built most of the Library and knew it best – had quit the company entirely because he was tired of dealing with the revolving door of product managers and the poor product leadership. The rest of the team was fragmented. They'd learned not to invest too much emotionally in any particular direction, because the direction would probably change when the next PM came along. That's a rational response to instability, but it's poison for product momentum.
Stakeholder Interviews to Surface Competing Product Visions
My first move was to stop building and start listening. I spent several weeks conducting stakeholder interviews across the organization — not just the Library team, but leaders from sales, customer success, engineering, executive leadership, and critically, people close to ScriptRunner itself. I wanted to understand what everyone thought the Library was for, how they saw it connecting to ScriptRunner's user base, and where they thought it fit into Adaptavist's broader strategy.
The interviews revealed exactly what I expected: multiple overlapping but distinct visions. Some stakeholders saw the Library primarily as a content marketing play — a way to attract ScriptRunner users and convert them into services customers. Others saw it as a retention tool — a resource that made existing ScriptRunner users more successful and less likely to churn. A few saw it as an education platform that could eventually stand on its own. And some were honest enough to say they weren't sure what it was supposed to be, only that it felt connected to ScriptRunner's value proposition somehow.
None of these visions were wrong. Each reflected a legitimate business need and a genuine opportunity. The problem was that pursuing all of them simultaneously meant pursuing none of them effectively. The team was trying to be everything to everyone, which in practice meant being nothing to anyone.
Establishing the Adaptavist Library Mission Through Systems Thinking
The stakeholder interviews gave me the raw material. The next step was synthesis — turning a collection of competing perspectives into a clear, shared understanding of what the Adaptavist Library should be and how it related to ScriptRunner.
I applied systems thinking to map the relationships between the Library, ScriptRunner, Adaptavist's other products, the customer journey, and the company's strategic goals. This wasn't abstract theorizing. It was practical analysis: Where does the Library create value for ScriptRunner users? How does that value feed back into the broader Adaptavist ecosystem? What happens if we invest more here versus there?
Through this analysis, I arrived at a mission statement that captured the Library's essential purpose: "The Adaptavist Library teaches people how to create solutions to unique problems."
That sentence did a lot of work. "Teaches" positioned the Library as educational, not just a script dump. "Create solutions" emphasized capability-building over dependency — the goal wasn't just to hand people pre-built Groovy scripts but to help them understand the patterns well enough to adapt scripts to their own environments. "Unique problems" acknowledged that every Jira or Confluence instance is configured differently, so cookie-cutter solutions only get you so far.
This mission was specific enough to guide decisions and broad enough to accommodate growth — including the eventual ScriptRunner integration. It provided a clear test for every feature request, content proposal, and roadmap item: Does this teach people to create solutions to unique problems? If yes, it's in scope. If no, it's not.
Applying Wardley Mapping to Product Strategy
With the mission established, I needed a framework for translating it into strategic priorities. I turned to Wardley Mapping – a technique for visualizing the components of a value chain and their evolutionary stage.
What Wardley Mapping Revealed About the Adaptavist Library
For those unfamiliar, Wardley Mapping plots the components needed to serve a user need along two axes: visibility to the user (vertical) and evolutionary stage from genesis to commodity (horizontal). The technique was developed by Simon Wardley and has gained significant traction in technology strategy circles because it surfaces assumptions that other strategy tools leave hidden.
Mapping the Adaptavist Library's value chain revealed several important insights. First, some components the team was building from scratch were actually commodity capabilities available off the shelf. That effort was wasted. Second, the components that were genuinely novel – the ones that differentiated the Library from generic documentation or training platforms – weren't getting proportional investment. Third, the relationships between components showed dependencies that explained why certain initiatives kept stalling.
Using the Map to Prioritize Product Investment
The Wardley Map became a communication tool as much as an analytical one. When stakeholders could see the entire value chain visualized, conversations about priorities became more productive. Instead of debating abstract feature requests, we could point to specific positions on the map and discuss whether investing in a particular component aligned with the Library's evolutionary trajectory.
I identified several areas where the team should stop investing (commodity components that could be replaced with existing solutions), areas where they should increase investment (differentiating components aligned with the mission), and areas where they should experiment (genesis-stage capabilities that could become future differentiators).
This wasn't a radical pivot. It was a strategic clarification. Most of what the team had been doing was valuable – it just needed to be organized around a coherent strategy rather than a collection of ad hoc decisions.
Securing Business Investment with Clear Product Direction
By May 2021, the results of this strategic work were visible in several ways.
The most concrete was securing additional business investment. When the Library had a clear mission, a mapped value chain, and a prioritized roadmap, making the case for investment became straightforward. Leadership could see exactly what they were investing in, why it mattered, and how it connected to Adaptavist's broader goals. That clarity didn't exist before.
I played a significant role here, and I want to be honest about what that involved beyond the strategy work. The three previous product managers had burned bridges with the ScriptRunner team to the extent that the ScriptRunner engineers actively wanted to get rid of the Library. This was supposed to be a platform supporting their flagship product, but they were just done with it. I had to rebuild those relationships, demonstrate the Library's value to the ScriptRunner team directly, and get them on board with the vision so they would contribute and consider integration down the road. That relationship repair was as important as the strategic clarity.
The business case was strong because the Library had genuine potential – its connection to ScriptRunner's massive user base made the opportunity real. Investment decisions at companies like Adaptavist involve many factors beyond product strategy, and there were other people advocating for the Library alongside me. But turning skeptics into allies, particularly on the ScriptRunner team, was a critical piece of getting the investment secured.
Energizing Cross-Team Collaboration at Adaptavist
The less tangible but equally important result was the shift in team dynamics. Once the Library had a clear mission and strategic framework, collaboration across divisions became natural rather than forced.
Content teams knew what kind of material to create. Engineering knew which technical capabilities to prioritize. Marketing knew how to position the Library. Customer success knew how to incorporate it into their work with clients. The mission served as a shared language that connected previously siloed efforts.
The team energy changed too. There's a specific kind of motivation that comes from understanding why your work matters and how it connects to something larger. The Adaptavist Library team had been doing good work in isolation. With strategic clarity, they started doing great work together.
Lessons from Defining Product Strategy Under Uncertainty
If there's a generalizable lesson from this project, it's that strategic ambiguity is more expensive than it appears. When a product lacks clear direction, the cost isn't immediately visible. The team keeps shipping. Metrics move. Things look fine on the surface.
But underneath, effort is being diffused across too many directions. Decisions are being made on inconsistent criteria. Talent is being underutilized because people can't connect their individual skills to a larger purpose. The compounding cost of that ambiguity is enormous — it just accrues gradually enough that it's easy to normalize.
The fix isn't complicated in theory. Listen to stakeholders. Synthesize competing perspectives. Establish a clear mission. Map the strategic landscape. Prioritize accordingly. In practice, of course, every one of those steps involves difficult conversations, organizational politics, and the discomfort of closing down possibilities to focus on the ones that matter most.
The Adaptavist Library had been through three product managers, each starting fresh and each leaving before their vision solidified. The CEO gave me a binary mandate — kill it or save it — and a few weeks of stakeholder interviews and Wardley Mapping were enough to show that the opportunity was real. My job was to build the strategic clarity that had been missing, and make it durable enough that it wouldn't evaporate with the next leadership change.
Frequently Asked Questions
How does Wardley Mapping differ from traditional product strategy frameworks?
Traditional frameworks like SWOT, Porter's Five Forces, or even lean canvas approaches tend to provide static snapshots. Wardley Mapping adds a dynamic dimension by showing where components sit on an evolutionary axis — from novel to commodity. This helps you see not just where you are, but where things are heading. For the Adaptavist Library, this meant seeing how the script repository related to ScriptRunner's evolution — identifying commodity components the team was over-investing in and differentiating capabilities (like the eventual in-app integration) that weren't getting proportional attention.
How do you define a product mission when stakeholders disagree?
You don't resolve disagreement by picking a winner. The stakeholder interviews I conducted for the Library revealed that most "disagreements" were actually different views of the same elephant. Sales saw the trunk, customer success saw the legs, engineering saw the body. The synthesis work is about finding the frame that honestly encompasses the valid elements of each perspective while being specific enough to guide decisions. The mission I arrived at – "teaches people how to create solutions to unique problems" – gave each stakeholder group a way to see their priorities reflected without diluting the direction.
What do you do when a product team has lost momentum after multiple PM changes?
Start by acknowledging the situation openly. The Adaptavist Library team had watched three PMs come and go — they knew the pattern, and they'd learned to be skeptical of anyone new claiming to have the answer. Earning trust meant doing the listening work first: stakeholder interviews, reviewing what each previous PM had started, understanding why initiatives stalled. The goal is to understand the accumulated context — all the half-finished work and partially completed pivots — before proposing a path forward. Then make the new direction tangible through artifacts (mission statement, Wardley Map, prioritized roadmap) that the team can reference independently. The artifacts matter because they reduce dependence on any single person's vision, which is exactly the vulnerability that caused the problem in the first place.
Related Case Studies
- Unifying Documentation for 25+ Atlassian Apps in Confluence – Another Adaptavist project where I brought clarity and structure to a fragmented landscape.
- Atlassian Implementation for a Health Insurance Startup: From 100 to 30,000 Members – A project where strategic expansion of scope led to transformative results.
- Enterprise Confluence Upgrade for 150,000 Healthcare Professionals – Project leadership under technical uncertainty, with a different kind of discovery process.