Problem

Every quarter at athena, over 200 teams across the organisation gather for what's internally known as the BURP — Bottom Up Release Plan. For three days, scrum teams sit in closed rooms anchoring on OKRs, writing EPICs, user stories, and acceptance criteria, then slotting them into 7-8 defined sprints for the upcoming release.

The complexity compounds quickly. Long-term roadmap alignment is imperative. Cross-team dependencies demand closer inspection of timelines and readiness. Story points need to align with developer bandwidth. Functional-to-technical work ratios must be factored in. With all of this happening in real-time across a room full of engineers, product managers, and other stakeholders, it's no surprise that teams fondly refer to it as Death by Grooming.

Solution

Rather than replacing the ritual entirely, I decided to redesign it by using a tool the team was already familiar with, but in this case, adding an AI layer on top.

We sat in the same room and joined a structured Microsoft Teams call with a defined agenda and clear guardrails to keep the conversation focused. To minimise or eliminate drift as much as possible. We moved through our planned scope in sequence, and three hours later, we had a complete meeting transcript with the help of Co-pilot. A few adjustments were made to the transcript before moving on to the next phase.

That transcript became the raw input for a carefully structured GenAI prompt. The output: PRDs with user stories and acceptance criteria, mostly estimated, with resource allocations mapped against the development team's known bandwidth and functional-technical work split. Not just documentation, but something very close to an actual release plan.

From there, MCP handled the rest. Work was pushed directly to Confluence and all stories were extracted into their respective Jira epics.

Impact

We saved over 18 hours of planning and discussion time. We closed out documentation for 90% of functional items planned — a figure many teams struggle with even after the full three-day event. In fact, the post-ritual expectation is a 4-sprint plan at a high level, with the first two sprints ready-to-go. And because of that, members were pre-occupied with having documentation in place to meet presentation deadlines, rather than focusing on the overall quality of the release.

The real change was less visible. The team wasn't exhausted. They were informed and more confident. The AI layer together with the MCP layer transformed the transcript into structure and eliminated most of the documentation-intensive work, leaving more time for deliberation and constructive planning.

What had been a gruelling, multi-day commitment became a focused, single-session workflow.

Death by Grooming doesn't have to be the cost of staying organised. The expressway exists — you just have to be willing to take it.

Problem

I've always found it fascinating that when someone shares their screen, the first few things you notice are their cluttered desktop and their unread email counts. It's either a sneak peek into their mind, their workday, or both.

For me, the next illuminating thing to watch for are their browser tabs. And PMs tend to have many of them open. 15 Jira tickets. 6 Confluence pages, 5 Amplitude dashboards, 4 Excel sheets, 3 PowerPoint decks, a year-old research paper, and a Fond points programme to grease someone's palms. I've seen worse.

The less glamorous truth is that we context switch constantly. But, we've all imagined a single place where everything can be referenced at a click.

Solution

So, after a recent Codex learning session, I hypothesised about building something like that. Dependencies aside, I stitched some of my frequented applications together.

Now, we use several applications at work, and being a highly-regulated industry, not all applications are connectable because of the data they carry. So, in the spirit of experimentation, I used what was within reach.

Here's what ended up inside it:

• Jira, with a live sprint view, stories with acceptance criteria, comments, and alerts when stories get updated
• Confluence with quick access to every page I've authored
• Amplitude with analytics embedded for every project or feature I work on
• Task management with a personal task list, a Kanban board to track progress, and an Eisenhower matrix for prioritisation
• A drag and drop Roadmap builder with a built in RICE model, including features and epics for quick socialising

The architecture includes a React frontend, a Node.js backend handling API calls, and browser localStorage. I brought in design components from Figma and eventually published a case study to Confluence using MCP.

Takeaway

Here's what's interesting. I probably say this more often than I should - I'm not a developer.

A few years ago, building something like this would be nearly impossible. It would mean scoping a project, finding engineering resources or buying a subscription, and probably settling for something simpler than what I had in mind.

I remember a time, earlier in my career, when I handed over specs for an inventory planning dashboard. It was an idea a couple of PMs wanted to pursue over countless papers, calculators, and Excel sheets. It felt helpless and hopeful at the same time. IT ensured everything was explained with the technical depth of a rocket scientist. Every iteration took days, sometimes weeks to see an outcome.

Instead, today, I described a problem. Worked with Codex using natural language. Iterated. A few hours later, I had something running.

I don't claim that everyone and their third cousin can build anything they want. That's not the point. There is no trade-off for technical competence. What I do think is that the barrier to spinning up something quick, isn't as high as it used to be.

Problem

Traditional feature development followed a somewhat disconnected, sequential pattern where Product, Engineering, and Design operated on separate swimlanes toward the same endpoint. Product managers spent hours crafting PRDs and user stories. Design handed off specifications after requirements were finalized. Engineering translated these artifacts into code, often discovering gaps mid-development that triggered additional coordination cycles. Documentation happened at the end for all parties, including downstream functions.

A feature estimated at 8 story points typically consumed 64 hours of development time. Any break in the chain created friction requiring additional interactions to resolve missing links. After development and unit testing, the branch was merged and passed on to QA for further testing and regression. On successful completion, product members would schedule downstream activities with cross-functional teams to bring the product to market, a timeline that could span 6 sprints (384 hours). But in the world of AI, do these timelines make sense?

Solution

Through three progressive experiments building real production features, a small team (1PM, 1Dev) evolved from using AI as a coding assistant to creating an integrated workflow spanning Product, Engineering, and Design. Each experiment expanded scope and deepened cross-functional integration.

Experiment 1 established the foundation using Windsurf AI for pattern-based development, delivering the Patient Implant History feature, complete with Redux state management, two-screen UI flow, and 80%+ unit test coverage, in just 16 hours or 2 days versus the original 8-day estimate. The key learning: AI excelled when given concrete patterns from existing codebases, learning team standards and development language.

Experiment 2 expanded upstream into Product workflows. Using LLMs (ChatGPT and Claude), I expedited PRD creation and generated comprehensive user stories with acceptance criteria, tasks that would take 4-6 hours, in under 1, accelerating documentation workflows by over 75%. I must state that the feature was well-scoped prior. With feature APIs in place, Engineering picked up the story and executed in less than 12 hours. Product now moved at a higher velocity, though Design remained in its conventional lane and workflows weren't truly integrated.

Experiment 3, the larger and more complex of the features, used the expressway. By implementing Model Context Protocol (MCP) to connect AI tools directly to Atlassian, Figma, and Windsurf, the team created a production line tying all three disciplines together. I crafted requirements using LLMs, auto-generated properly structured Jira stories through Atlassian integration, including downstream material required to release the feature. Designs were built to requirements in Figma, and Windsurf pulled complete context through MCPs to understand what to build, why, and how it should function. The feature reached integration-ready status in 4 days instead of the estimated 16 days, with all disciplines contributing to a shared, AI-augmented process.

Impact

The transformation delivered quantifiable efficiency gains: development time reduced saving the team 212 hours, PRD creation accelerated user story generation by 70%, TRR and PRR documentation time was cut significantly by 80%.

TRRs use confluence pages. They adhered to standards. PRRs use PowerPoint slides. Conformity with slide specs was a challenge I didn't overcome.

Beyond metrics, the work fundamentally changed what's possible with existing teams. Product managers elevated from documenters to orchestrators, focusing on strategic thinking around user problems and clinical workflows. Engineers shifted from writing boilerplate to architecting systems, concentrating on performance optimisation and integration challenges. Design moved from middle-step handoffs to embedded collaboration, with specifications becoming living context.

Most significantly, this enables small teams to achieve what previously required larger headcount, speeds up innovation time for novel problems and creative solutions, and accelerates healthcare software development where speed directly translates to patient care impact.

AI-assisted development reimagines how Product, Engineering, and Design collaborate by transforming sequential handoffs into parallel workflows. Once you know the expressway exists, there's no going back.

Problem

Andrew Ng observed that AI makes development faster, but shifts the bottleneck to product management. When engineering can compress sprint-level work into hours and deliver features in days instead of weeks, the question shifts from "how fast can we build?" to "what should we build next?"

Traditional product workflows, like processing research data, crafting PRDs, generating user stories, creating go-to-market materials, drafting release communications, etc. operate at human-like speed while development moves much faster.

This velocity mismatch creates a new form of organisational friction. The bottleneck has simply moved upstream from execution to strategy and planning. That throughput will shift to the next weakest link in the chain until a system is optimised for building in an AI world.

Solution

If development cycles compress through AI assistance, product workflows must accelerate proportionally to maintain organisational speed. I experimented with GenAI across the entire product spectrum to test this premise, transforming how product managers leverage, create, and share assets. I first mapped out the existing cycle from concept to market, then repurposed a key data source to generate assets for each functional node.

Using MCP, I pulled research into thematic analysis. Distilled what to focus on - now, next, later. Brainstormed with GPTs to clarify, challenge, and convince. Organised everything into projects and used structured prompts and skills to synthesise everything into usable assets.

High-volume qualitative data, complex, nuanced customer feedback, research transcripts, and feature requests, distilled through AI analysis into actionable feature opportunities with supporting evidence and user context. PRDs became source material rather than endpoints and helped generate marketing material, training documentation, release notes, FAQ content, and stakeholder communication plans through AI transformation. User stories with comprehensive acceptance criteria materialised faster than ever. What's interesting and encouraging is that these activities took hours instead of weeks too.

Impact

Taken with a pinch of salt, the results are promising, and demonstrate that product velocity could match AI-accelerated engineering cycles. Product managers reclaim time previously spent on manual documentation work, reallocating focus toward strategic thinking, stakeholder alignment, user research, and complex prioritisation decisions that AI cannot handle independently. However, the stress of sustaining a consistent pace over extended durations makes this highly unreliable.

The broader implication validates Ng's observation while providing a path forward: when AI accelerates any part of the product development lifecycle, every adjacent function must compress proportionally or become the new constraint.

Problem

Clinical inbox workflows are highly repetitive yet context-dependent. Physicians, nurses, and medical assistants process hundreds of inbox items daily—lab results, patient cases, imaging reports, referrals. Currently, users manually navigate and select appropriate actions for every Inbox item, creating unnecessary interaction friction. On mobile devices especially, these extra taps compound inefficiencies, slowing task completion and reducing overall throughput. While not a blocker, this represents a significant opportunity: even saving one click per action, multiplied across thousands of daily interactions, could meaningfully improve productivity.

Solution

The original implementation used simple frequency to establish the most probable action. It would then re-sequence the action menu to rank actions by order of probability. Precision scores hovered around 20%.

This feature leverages ARM to predict the most likely next action when a user opens an inbox item, surfacing that recommendation as a floating action button (FAB) within the detail screen. The prediction model analyses historical behavioural patterns across multiple contextual inputs. Like document type, user type, document stage etc.

When confidence exceeds the 70% threshold, the system displays the recommended action prominently while maintaining an "All Actions" override option, preserving user autonomy. The approach balances intelligent assistance with user control—nudging efficiency without forcing automation.

Initial analysis looked promising with precision moving up - closer to 40%. The missing ingredient turned out to be an expensive option. And costs proved difficult to shy away from.

Impact

Success metrics target measurable workflow improvements on mobile: Like a 20% reduction in task completion times and 15% increase in inbox action volume etc.

The broader strategic value lies in establishing a foundation for intelligent workflow assistance across the platform. By demonstrating that ARM can meaningfully reduce decision fatigue while respecting clinical judgement, this feature opens pathways for expanded AI integration throughout the athenahealth ecosystem, ultimately enabling clinicians to divert more energy to patient care rather than administrative navigation.

Unfortunately, the feature was shelved due to resource bandwidth.

Problem

The healthcare industry loses over $150 billion annually to appointment no-shows. Protecting even 1% of these lost appointments translates to $1.5 billion in recovered revenue. Most scheduling systems lack the sophistication of predictive intelligence to identify high-risk appointments or surface contextual patient information that could inform better booking decisions, double-booking strategies, or proactive outreach.

Solution

This solution includes 4 phases of development. One such phase introduces predictive analytics generating probability risk scores for patient no-shows based on historical attendance patterns. Other phases include a set of contextual variables and weights. For instance, social determinants of health. This intelligence surfaces during booking, helping practices make informed decisions to ensure higher probability of attendance, thus protecting revenue.

This project would need significant work with data science as it scales. The initial phase would be a simpler mathematical calculation. I used Balsamiq and Lovable to build a few quick prototypes to show stakeholders how this would work out on mobile.

Impact

Significantly, the predictive analytics component directly impacts revenue models. For athena, that's a percentage of payments recovered. By identifying high-risk appointments and surfacing actionable patient insights, practices can implement strategic interventions to reduce no-shows, protecting slot utilisation, and maximising revenue potential for stakeholders.