Blog

All the latest news and updates – the product, the company and the people

Sign up for our quarterly tech round-up

You may unsubscribe at any time. Read our Privacy Notice.

Members of our team having fun at our annual innovation day event
AI & AutomationNews & UpdatesProduct & Design

How Epics Become Features: A Peek into Our Engineering Workflow

Every feature our customers use starts as an idea — but turning that idea into something reliable, scalable, and valuable takes more than just code. It takes collaboration, clarity, and a well‑thought‑out process.

In this blog, we’re sharing a behind‑the‑scenes look at how an epic moves from concept to customer‑ready feature at our company. While there are many supporting activities involved, this overview highlights the key stages that keep our teams aligned and our delivery predictable.

 

From Idea to Epic

The journey begins when the Product team drafts an epic, usually led by a Product Manager or Product Owner. An epic captures the problem we’re solving, the value it delivers, and the expected outcome — without getting into implementation details too early.

This keeps the focus on why we’re building something before we decide how to build it.

 

Epic Submission: Creating Shared Context

Every week, new epics are presented in a scheduled Epic Submission meeting, attended by representatives from multiple projects and teams.

This session helps us:

  • Align early across teams
  • Identify cross‑team dependencies
  • Surface risks and overlaps
  • Build a shared understanding of upcoming work

By addressing dependencies upfront, we reduce surprises later in the development cycle.

 

Ownership and Cross‑Team Alignment

Each epic is owned by the team responsible for most of the work. The owning team then coordinates discussions with any dependent teams to dive deeper into:

  • Requirements and scope
  • Technical considerations
  • Possible solution approaches

These conversations allow each team to provide estimates and ensure everyone is aligned before moving forward.

 

Estimation, Feasibility, and Prioritization

Once estimates are gathered, the epic moves into prioritization, helping determine when and how it should be implemented — whether teams work in parallel or sequentially.

Before development begins, the Product Owner reviews the epic with senior engineers to assess feasibility. Together, they discuss:

  • Technical challenges
  • Impact on existing systems
  • Long‑term maintainability

This step ensures we commit to solutions that are both practical and sustainable.

 

Keeping the Whole Team in the Loop

After feasibility review, the epic is presented to the entire engineering team. This gives everyone visibility into what’s coming up and how it fits into the broader product roadmap.

Clear communication at this stage helps teams feel informed and prepared — not caught off guard.

 

Dev Handoff: Designing the Solution

Next comes Dev Handoff, where one engineer takes responsibility for designing the detailed solution. The proposed design is reviewed with the whole team, encouraging open discussion and feedback.

The Product Owner also joins this session, which helps translate the solution into well‑defined user stories that are ready for implementation.

 

From Epics to Sprint‑Ready Stories

Once user stories are drafted, they’re reviewed in a 3‑Amigo session — involving the Product Owner, a developer, and a QA engineer. This ensures each story has enough clarity and detail to begin work confidently.

The stories are then discussed with the full team during refinement, where engineers clarify requirements and provide estimates. During sprint planning, stories are scoped into the sprint for development and testing.

 

Safe Releases with Feature Flags

To avoid blocking releases due to cross‑team dependencies, we use feature flags. This allows teams to deploy code safely while controlling when functionality is exposed to customers.

Once all stories related to an epic — including those owned by other teams — are completed, the feature flag is toggled and the new functionality becomes available to users.

 

More Than a Process

Behind this workflow are many additional practices like performance testing, demos, and iteration as new information emerges. But at its core, our approach is built around collaboration, transparency, and engineering ownership.

For our customers, this means dependable features that solve real problems.
For our engineers, it means clear context, early involvement, and the ability to influence solutions end‑to‑end.

If you enjoy working in an environment where ideas are thoughtfully shaped into impactful outcomes, this is how we build — together.

SHARE THIS ARTICLE

Jump to the good bits