Applying Shape Up for Data Product Teams

The best way to look at a problem is not to view it as a problem at all but as an opportunity to grow stronger, more skilled, more confident. - John C. Maxwell

The Continuous Sprint Dilemma

Six months into leading Revive's data product team, I faced a familiar problem. Midway through our fourth consecutive two-week sprint on the Patient Journey Analyzer, team morale plummeted.

"We constantly plan but never finish," complained our data scientist. "We keep pushing the interesting modeling work to the next sprint."

"The UI keeps changing because we don't have time to explore visualization options properly," added our designer.

Our tech lead nodded silently, clearly frustrated.

These complaints weren't new. The agile sprint methodology that served our marketing products well created specific strain for our data products. The relentless cycle of planning, executing, and reviewing fragmented our work and prevented deep thinking on complex data problems.

After discovering Ryan Singer's "Shape Up" methodology from Basecamp, I proposed a shift to my team and leadership: "Let's abandon our two-week sprints and try a completely different approach for our next data product."

Six weeks later, we delivered the most polished, well-architected data product in our company's history—with an energized rather than exhausted team.

Shape Up is a framework built on the Agile Manifesto (go read it, still an absolute classic and relevant today)

Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Like Data Driven Scrum, CRISP-DM or other frameworks that focus on flexibility in probabilistic outcomes, Shape Up is a great fit for the unique challenges of data product teams.

if only t.hanks would say this to me daily

The Unique Challenges of Data Product Development

Data product development differs fundamentally from traditional software development in several key ways:

Data exploration involves inherent uncertainty: Unlike feature development with well-defined specifications, data work includes exploratory phases with unpredictable timelines and outcomes.
Ethical questions require thorough deliberation: Data products, particularly those using algorithms or AI, present complex ethical challenges that demand more than rushed sprint planning discussions.
Technical and UX decisions intertwine: Your data model directly affects what users see, creating interdependencies difficult to resolve in small time boxes.
Specialists need uninterrupted focus: Your data scientist designing a complex feature engineering pipeline loses valuable momentum when forced to shift focus for sprint planning.
Integration testing demands methodical verification: Ensuring proper data flow through every system layer requires comprehensive testing that rarely fits neatly into sprint boundaries.

Traditional agile frameworks - like Scrum or SAFE, with their push for short time boxes and constant planning, often hinder progress on these complex data product challenges.

Shape Up: Tailored for Data Product Teams

Shape Up offers a refreshing alternative to continuous sprint cycles, with principles that align perfectly with data product team needs:

1. Six-Week Cycles Replace Two-Week Sprints

Six-week work cycles provide data teams crucial advantages:

Adequate data exploration time: Six weeks allows teams to properly explore datasets, test multiple modeling approaches, and implement the optimal solution.
Space for ethical consideration: Longer cycles enable thoughtful discussion of ethical implications impossible to address in packed sprint planning sessions.
Freedom to tackle fundamental problems: When data scientists and engineers know they have six uninterrupted weeks, they solve architectural challenges properly rather than applying temporary fixes.

As our data architect noted during our first Shape Up cycle: "I finally have permission to solve the problem correctly instead of just meeting stupid Friday deadlines."

when that VP of sales sells a feature before its built

2. Shaping Work Before Commitment Improves Outcomes

In Shape Up, teams "shape" projects before committing to a cycle—defining the problem, outlining a solution, and identifying risks and boundaries. You always need this in building products but becomes crucial in complex data products. Scrum has these ceremonies but after multiple attempts at different companies, this "double diamond" section always gets squeezed.

Steps to shaping

Shaping has four main steps that we will cover in the next four chapters.

Set boundaries. First we figure out how much time the raw idea is worth and how to define the problem. This gives us the basic boundaries to shape into.
Rough out the elements. Then comes the creative work of sketching a solution. We do this at a higher level of abstraction than wireframes in order to move fast and explore a wide enough range of possibilities. The output of this step is an idea that solves the problem within the appetite but without all the fine details worked out.
Address risks and rabbit holes. Once we think we have a solution, we take a hard look at it to find holes or unanswered questions that could trip up the team. We amend the solution, cut things out of it, or specify details at certain tricky spots to prevent the team from getting stuck or wasting time.
Write the pitch. Once we think we’ve shaped it enough to potentially bet on, we package it with a formal write-up called a pitch. The pitch summarizes the problem, constraints, solution, rabbit holes, and limitations. The pitch goes to the betting table for consideration. If the project gets chosen, the pitch can be re-used at kick-off to explain the project to the team.

Properties of Shaped work:

Property 1: It’s rough
1. "Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go."
Property 2: It’s solved
1. "Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. The work isn’t specified down to individual tasks, but the overall solution is spelled out."
Property 3: It’s bounded
1. "Lastly, shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out."

shape up for that sprint - otherwise you'll pull something. likely your ego.

In our current role, during the two-week shaping process for our Risk Stratification Engine:

Our data scientist identified serious data quality issues, allowing us to fix the data pipeline before committing development resources
Our product and design leads tested multiple visualization approaches and selected one that better conveyed prediction uncertainty
Our tech lead spotted a potential performance bottleneck in real-time scoring and designed an elegant caching solution

By the time we started the six-week cycle, we understood better what we needed to build and knew it was both valuable and feasible.

3. Betting Table Forces Strategic Resource Allocation

Shape Up replaces endless backlogs with a "betting table" where stakeholders decide which shaped projects deserve resources in the upcoming cycle.

For data products competing for limited specialist resources, this drives crucial prioritization discussions:

"Does this machine learning model justify six weeks of our data science team's time versus the visualization engine?"
"Do we trust the data quality enough to bet on this project now, or should we improve it first?"
"Is this ethical concern significant enough to address before proceeding?"

The betting table got us out of tactical backlog management to meaningful bets. Also don't worry, you will forget something. Important ideas (the ones that make or break the trajectory of a product) come back.

4. Fixed Time, Variable Scope Enables Better Decisions

Most importantly, Shape Up embraces "fixed time, variable scope"—liberating for data products where exploration and discovery drive the process.

every prod eng before the end of a scrum sprint

Rather than creating arbitrary deadlines that force teams to compromise data quality or ethical considerations, they can:

Deeply explore the most critical aspects of the problem
Make deliberate scope decisions based on discoveries
Deliver valuable solutions after six weeks, even if they differ from initial expectations

This fundamentally changes how teams measure success—from "did we complete all sprint stories?" to "did we solve the core problem effectively and responsibly?"

Shape Up in Action: A Healthcare Data Product Case Study

Here's how we applied Shape Up to develop a healthcare provider recommendation engine matching patients with specialists based on their conditions, insurance, location, and care needs for a health system - during my days at a healthcare marketing agency.

The Shaping Phase

Before committing to a six-week cycle, our Product Squad (Product Manager, Tech Lead, Design Lead, and Data Lead) shaped the work over two weeks:

Problem Definition: We narrowed "help patients find doctors" to "match patients with specialists for their specific chronic condition based on provider expertise, location, and insurance compatibility."
1. Combination of claims + de-identified patient summaries got the fields in place.
Appetite Setting: We committed a full six-week cycle from our core team rather than fragmenting it across multiple sprints alongside other work.
Solution Exploration: Our Data Lead tested multiple matching algorithms and recommended a hybrid approach balancing relevance with explainability.
1. Fuzzy match in Alteryx + scipy augmentation if yall remember those days
Risk Identification: We pinpointed specific risks, including provider directory data freshness issues and potential recommendation bias.
1. Definitive kept us up to date
Boundary Setting: We deliberately excluded provider quality metrics since the available data lacked reliability across specialties and regions.

The resulting pitch provided clear direction with established boundaries, guiding the team while leaving room for implementation problem-solving.

The Six-Week Cycle

With clear shape established, our cross-functional team built the recommendation engine over six uninterrupted weeks:

Weeks 1-2: The team mapped the entire solution into discrete "scopes" and tackled the highest-risk component first: the matching algorithm.

Weeks 3-4: With the core algorithm working, they integrated the provider + patient data pipeline and built the user interface for search criteria.

Weeks 5-6: They implemented the results display, refined the algorithm based on testing, and added features like saved recommendations and sharing.

Throughout, they used "hill charts" to visualize progress—tracking how components moved from "figuring it out" to "getting it done" rather than merely counting completed tasks.

don't be ralph - fall down with purpose.

The Results

At the end of six weeks, we delivered a fully functional provider recommendation engine to our client that:

Matched patients with specialists based on their specific conditions
Accounted for insurance compatibility (payor, plan, and overlap period) and location preferences
Provided transparent explanations for each recommendation
Respected HIPAA and BAA agreements
Included filtering by service line and geo regions

We shipped a complete working product that delivered immediate value—not a prototype requiring additional sprints. The team emerged energized rather than exhausted. Our Data Lead said, "This is the first time we've had space to build something properly from the ground up."

Implementing Shape Up for Your Data Product Team

Start transforming your data product team with these five steps:

1. Begin with One Cycle

Test Shape Up with a single six-week experiment:

Select one meaningful data product initiative
Dedicate a cross-functional team for six weeks
Protect them from other responsibilities during this period
Evaluate results before expanding the approach

2. Adapt Shaping for Data Products

When shaping data product work, focus on:

Data quality verification: Confirm necessary data is accessible and reliable before committing
Ethical boundary setting: Address potential biases, privacy concerns, and governance requirements explicitly
Technical feasibility testing: Run proof-of-concepts on complex algorithms or data pipelines
Visualization prototyping: Test how users understand complex data through different presentation methods

3. Build a Complete Data Product Squad:

Assemble that product squad and learn more about it here! Beyond the Product Trio - Why Data Products Need a Squad

A Product Manager with data product expertise
A Tech Lead focused on data architecture and performance
A Design Lead skilled in data visualization
A Data Lead with data science, engineering, and ethics knowledge
If vertical or regulated, you might need a SME such as a clinical lead for healthcare or lawyer for lawtech

4. Use Hill Charts for Visibility

Adopt hill charts to visualize data product progress:

The uphill phase shows data exploration, model design, and approach development
The downhill phase represents implementing the chosen solution
Moving components "over the hill" indicates resolved uncertainty

This gives stakeholders meaningful progress visibility without demanding arbitrary completion percentages that make little sense for exploratory data work.

5. Create Breathing Room Between Cycles

Take two weeks after each six-week cycle to:

Refine data pipelines needing attention
Address minor issues discovered during the cycle
Explore approaches for the next cycle
Deliberately select your next highest-value initiative

This "cool-down" period prevents teams from rushing into new work without reflection. Easiest way to burn team out and go off the rails is to string poorly shaped work back to back. give folks a break

go chill like bluey every once and while

The Questions Worth Asking

As you consider applying Shape Up to your data product team, reflect on these thought-provoking questions:

How might longer, uninterrupted cycles change the ethical considerations in your data product development?
Could the shaping process help identify data quality issues earlier in your workflow?
What would happen if your data scientists could explore multiple approaches without daily standup pressure?
How would your data visualization strategy change if designers had more time to experiment before committing?
What organizational resistance might you encounter, and how will you address it?

Beyond the Sprint Treadmill

Data product development demands space for exploration, ethical consideration, and deep technical work that doesn't fit into two-week sprints.

Shape Up respects the unique challenges of data work while maintaining the discipline required to ship products.

For my team, adopting Shape Up shifted our entire mindset—from constant planning to thoughtful shaping and focused execution. For a few of my teams, it resulted in better data products, happier team members, and more strategic decisions about what we build and why.

If your data product team suffers from sprint fatigue, cuts ethical corners due to time pressure, or accumulates technical debt because there's "never time to do it right," Shape Up offers a way out. It's the ideal of the Agile Manifesto in my opinion

In data products, sometimes you move faster by slowing down—taking time to shape work properly, commit appropriate resources, and give your team space to build something truly valuable.

I'd love to hear your thoughts!

Have you tried alternative methodologies for data product development? What challenges have you faced with traditional agile approaches?