Intelligent Atlassian implementationsfor complex and regulated product teams.
A template sets up a tool. We set up the questions it has to answer, so your team finds a gap the day it happens, not the night before a release.
The flow of work
The memory
The way back in
The why
The second pair of eyesThe Jira nobody designed
Did you ever open the Jira admin page and find 47 statuses, 212 custom fields and a workflow called “DO NOT USE – v2”?
Nobody planned it. Every field was a good answer to someone’s problem, once. A status for the auditor. A field for the customer who asked about delivery dates. A second workflow when the first one got in the way.
Now the tool records everything and answers nothing. Ask it which requirements still have no test, which build is blocked by a late part, or why the team is building this feature, and someone exports to a spreadsheet.
So people work around Jira instead of in it. And the one person who understood the setup left last spring.
| Ready for review |
| Ready for review (QA) |
| Ready for review – OLD |
| Waiting |
| Customer date |
| Customer date 2 |
| Audit flag (do not use) |
DO NOT USE – v2
Fewer fields. More meaning.
That’s what we mean by an intelligent implementation. Follow one change through all five tools: every step keeps its link to the last, so the answer to any question is already there.
Jira Product Discovery · The why
It starts with a reason
Fourteen customer insights point at the same problem: the dose alert fires too often. In Jira Product Discovery the idea is scored on evidence, not on the loudest call. When it’s ready, a delivery work item is created in Jira, with the insights carried over.
Designed backwards from the questionsIDEA-21 · Idea
Dose alert threshold
Insights 14Impact highEffort medium
Delivery work item created
Jira · The flow of work
It becomes work you can trace
The idea becomes a requirement in Jira. The link back to IDEA-21 is kept, and its progress shows on the idea. If it moves on without a test or a risk control linked, an automation rule flags it the same day.
The rules live in the toolREQ-014 · Requirement
Dose alert threshold
In progressFix version 2.5
IDEA-21from ideaRC-007risk controlTST-022verified by
Confluence · The memory
The decision is written down
Why the threshold changed, who decided and what was considered sits in Confluence, linked to REQ-014, with every version kept and the approval recorded. Next year, nobody has to remember.
Written down, so nobody has to rememberDesign history · Decision
DEC-031 Alert threshold per patient
Linked to REQ-014v3
Approved by Quality
Jira Service Management · The way back in
The field talks back
After release a clinic reports the alert still fires at night. The request lands in Jira Service Management, the agent links it to REQ-014, and design sees it, not just support.
Nothing gets lost on the way backFR-88 · Field request
Alert fires too often at night
Linked to REQ-014Back to design
Rovo agents · The second pair of eyes
Something checks the gaps
Before release 2.5 ships, a Rovo agent reads the links and points at what is missing, so the gap is found on a Tuesday afternoon, not the night before.
A second pair of eyes before releaseRovo agent · Release check
Release 2.5: 1 requirement without a test
REQ-019 Alarm volume
Want to know how far your Jira is from this?
Take a free checkSame five tools, set up for your kind of team
Complex and regulated teams don’t need more of Jira. They need the parts that answer their questions.
JiraConfluenceJira Service ManagementJira Product DiscoveryRovo agentsWhere are you starting from?
The method is the same. The first month is different.
Starting fresh
You are moving off spreadsheets, another tool or a first Jira site that grew by accident, and want it right the first time.
Untangling a Jira that grew
Years of fields, statuses and workflows nobody owns. We keep what works, retire the rest and move the data you still need.
Bringing teams onto one setup
Several projects, sites or teams that each run Jira their own way, and no report anyone trusts.
Who does the work
Big partners are built for company-wide roll-outs. We’re built for the product team where the head of quality is also the Jira admin.
Lottusa is led by Ewa Kasiak, our founder, with a network of Atlassian experts who deliver through one stage-gated method.
- We build on the platform too: Gatecast for Jira, our own app for stage-gated hardware plans.
What you hold at the end
Not a slide deck. The working setup, and everything your team needs to keep it working.
The setup itself
Jira · Workflow
Rule: no release without a verified by link
Work types, workflows, links, boards and spaces, configured and tested on your site.
“Where does a requirement go when it’s verified?”
A decision log in Confluence
Confluence · Decision log
| DEC-012 | Status “Verified” added |
| Why | Release needs a passed test |
| Agreed | Head of quality, 14 Mar |
Why every status, field and rule exists, and who agreed it.
“Why do we have this field?”
A one-page map of your flow
One-page flow map
How work moves from insight to release, for new joiners and auditors alike.
“How does work move here?”
The data you chose to keep
Data move · checklist
- Work items with links
- Design documents
- History that still matters
- Old workarounds: archived
Moved, linked and checked; the rest archived, not lost.
“Did our history make it across?”
Dashboards that answer real questions
Dashboard · Release 2.5
The gaps, the risks and the dates your leadership actually asks about.
“What’s still open before release?”
Admins who can run it
Training · agenda
- Admins · changing a workflow safely
- Team · the flow, day to day
- Leads · reading the dashboards
Training for your admins and the people who use it every day.
“Who can change a workflow?”
What we don’t do
- No Server or Data CenterWe work on Atlassian Cloud only.
- No copied templatesYour setup starts from your questions, not our last client.
- No sign-off on your quality systemYour quality or regulatory lead owns that. We make their evidence easy to produce and easy to show.
- No framework roll-outsWe don’t install SAFe. We set up the flow your teams will actually keep.
How an implementation runs
Five stages of the Product Ops Flywheel, each ending with something you can see. How the Flywheel works →
- 01TeardownYour Jira and Confluence reviewed: gap list and a way forward
- 02BlueprintThe target flow designed, one feature traced live
- 03ImplementSet up, data moved, team trained
- 04EnhanceAutomation, dashboards, Rovo agents
- 05ThriveA quarterly health review
Questions about implementations
What is a Jira implementation?
A Jira implementation is the work of setting up Jira for how a team plans, builds and releases: work types, workflows, links, boards, permissions and reports, plus the Confluence spaces and automation around it. Done well, it turns the tool into the team’s single flow of work, not a ticket list.
Can’t we do this ourselves with templates?
You can start that way, and many teams do. Templates give you statuses and fields; they don’t know which questions your regulator, customers or board will ask. That’s usually how the Jira nobody designed begins. We start from those questions and write down why every field exists, so your own admins can keep it clean.
How does this fit our quality management system?
Your quality or regulatory lead owns the QMS and decides what the tools must do. We configure Jira and Confluence around those procedures and document the configuration, so your team can validate it and show the evidence.
How long does it take, and how is it priced?
The Teardown is free. It ends with recommendations across product, people, processes and tools: the gap list and a suggested way forward, so you know the scope before the build starts. How long the rest takes depends on how many teams, products and tools are involved.
Do you move our existing data?
Yes, the data you decide to keep: work items, links, documents and history that still matter. In Teardown we agree what moves, what is archived and what starts fresh, so the new setup isn’t cluttered by old workarounds.
Do we need Jira Premium?
Not always. Some features need Premium or Enterprise: Jira Plans for cross-team timelines, work type levels above epic, and native page approvals in Confluence. In Teardown we tell you which features you’d actually use, and whether they justify the upgrade.
Do you use Marketplace apps?
Only where Jira and Confluence can’t do the job on their own, for example test management, electronic signatures, approvals on Confluence Standard, or a workflow step that must block until a link exists. We recommend; you choose and buy them directly from the Atlassian Marketplace.
Is Rovo included, or extra?
Rovo search, chat, agents and Studio come with paid Atlassian Cloud plans (Standard, Premium and Enterprise), with a monthly allowance of Rovo credits per user. We set up agents that fit inside that allowance, and tell you up front if your use would need more.
Who owns the setup afterwards?
Your team. We train your admins and leave written decisions for every workflow and field, so changes after go-live stay consistent.
Bring us the Jira you have.
A review call is where most implementations start. In 45 minutes:
- You tell us how work flows today, and what you need to prove or decide.
- We look at your current Jira and Confluence setup, or your plan if you’re starting fresh.
- You leave knowing where the gaps are and what we’d do first.