I tried Pandora‘s brilliant method for feature prioritization. Here‘s what I learned.

As a data leader, one of the hardest parts of the job is deciding what not to build. With a never-ending stream of stakeholder requests and limited engineering bandwidth, ruthless prioritization is essential. But all too often, the prioritization process devolves into political jockeying, with decisions based more on who shouts loudest than what creates the most value.

I faced this challenge head-on when I joined my current company as the first data engineer. After spending several months standing up our foundational data platform, I suddenly had a flood of inbound feature requests from teams across the org. Don‘t get me wrong – this was a great problem to have! It meant people were bought into the promise of being data-driven.

But as a team of one, there was no way I could deliver on everything. I‘d either disappoint people by saying no constantly, or burn myself out trying to juggle too many competing priorities. I needed a transparent, objective approach to decide what to build and get everyone aligned.

That‘s when I came across Pandora‘s prioritization method. On the surface, it seemed almost too simple – could a stack of sticky notes really solve all my prioritization pains? I was skeptical but decided to give it a shot for our Q3 roadmap planning. The results blew me away.

Here‘s an inside look at how I adapted Pandora‘s method for my data team, the benefits and challenges I encountered, and my tips for giving it a try yourself.

Growing pains of a successful data team

To understand why prioritization is so hard, it helps to peek behind the scenes of a typical data organization. As data engineering lead, my job is to make sure our company has the infrastructure and processes to ingest, store, transform and analyze data at scale. But I don‘t get to dictate how that data ultimately gets used – that‘s up to our business stakeholders.

The good news is that demand for data insights is through the roof. In the past year, the number of "customers" my data platform serves has nearly doubled:

Metric	Q3 2021	Q3 2022	YoY Growth
Monthly active PBI users	35	60	71%
Quarterly feature requests	12	22	83%
Looker explores created	40	75	88%

That‘s incredibly validating and motivating. It means our initial data investments are paying off and appetite is growing. But that success has created a whole new set of challenges.

To keep up with demand, I‘ve had to ruthlessly prioritize the core data platform and tooling over ad hoc requests and "nice-to-haves". We simply can‘t afford to take our eye off the ball when it comes to reliability, scalability and security. Here‘s how my time breaks down in a typical week:

Meanwhile, the volume and complexity of incoming feature requests is exploding. We‘re being asked to onboard entirely new data sources, build out complex data models, and productionize machine learning pipelines. All awesome and impactful stuff – but each one is a heavy lift.

The tension really comes to a head during quarterly roadmap planning. As a platform team, I think it‘s critical that we take a holistic view and prioritize the most leveraged investments – those core APIs, schemas, and frameworks that unlock value for many teams. But to an individual stakeholder, their own team‘s reporting or analysis needs always feel most pressing.

In the past, I tried to gather wish lists and determine priorities in 1:1 conversations with stakeholders. But inevitably, when we announced the final roadmap, people would be confused or frustrated that their pet project didn‘t make the cut. We‘d end up revisiting decisions and needing to explain constraints and trade-offs over and over. Not exactly a recipe for happy, engaged stakeholders!

I knew we needed a more inclusive, transparent and objective approach. Ideally one that:

1. Surfaces everyone‘s needs and perspectives
2. Creates shared context on capacity and constraints
3. Drives collaborative decision-making based on company-wide impact
4. Leaves stakeholders feeling heard and bought in, even if their request didn‘t get prioritized

When I read about Pandora‘s prioritization method, I realized it checked all those boxes and more. I was excited to give it a try, with a few tweaks for a data org context.

Adapting Pandora‘s method for a data team

Here‘s a quick refresher on how Pandora‘s prioritization process works:

1. Collect feature ideas from stakeholders across the company
2. Summarize each one in a slide capturing user benefits and success metrics
3. Assign a cost to each based on required engineering time
4. Give decision-makers a "budget" of votes to allocate across features
5. Discuss as a group to align on final priorities within capacity constraints

To make it work for my data org, I adapted a few specifics while keeping the core approach the same:

• Instead of opening the floodgates, I met proactively with leads of key partner teams to understand their upcoming needs and brainstorm high-impact data features
• For the voting "currency", I used a scale of $10 per day of data engineering effort to build (vs. $5 per engineer-month in Pandora‘s model)
• I included not just new feature development but also maintenance and ad hoc support in the total capacity, since those are a big part of my job in practice

With those parameters in place, I was ready to give it a shot! I collected a total of 22 feature ideas from my partner teams and estimated it would take about 80 engineer-days ($800) to deliver them all.

The only problem? I only had 36 engineer-days ($360) to allocate in the quarter based on my target of spending 60% time on roadmap features. We‘d have to make some hard choices and leave a lot of good ideas on the table.

I‘ll admit I was nervous going into the prioritization meeting. Would the execs revolt at being asked to make trade-offs so starkly? Would they go into "used car salesman" mode and just try to convince each other? I hoped that having the right people in the room – those with a holistic view of company priorities – would keep things on track.

Seeing it in action

The big day arrived and I kicked off the session with a quick overview of how the process would work. I shared the 22 feature "candidates", along with the estimated cost of each one. The grand total was more than double my available capacity for the quarter. There were audible gasps in the room as people realized how much was being asked of such a lean data team.

I gave each decision-maker their "budget" of stickies to allocate, then set them loose to discuss, horse trade, and ultimately vote by placing stickies on the features they wanted to fund. It was fascinating to watch people‘s thinking evolve in real time.

At first, most execs put their votes toward the features that would directly benefit their departments. But as the conversation unfolded, you could see the mental gears turning. They started asking probing questions about which investments would most accelerate the business as a whole.

One pivotal moment was when our Head of Product spoke up and said, "I really want the new user retention dashboard for my team. But if I‘m being honest, the marketing attribution pipeline would be a bigger unlock for the company right now. I‘m going to move my stickies there." That sparked others to reevaluate their votes with the greater good in mind.

After much spirited discussion, the dust settled and we had a prioritized roadmap. Of the original 22 feature ideas, only 5 remained fully funded – a measly 23%! Some really great projects didn‘t make the cut. But critically, we now had stakeholder alignment that these were the right 5 to focus on for maximum impact.

Feature	Engineer Days	Status
Marketing attribution pipeline	20	Funded
Real-time product metrics API	15	Funded
Supply chain analytics platform	30	Funded
Customer 360 data model	25	Funded
Forecasting & planning tool	30	Funded
User retention dashboard	5	Partially funded
…16 more features…	10-30 each	Not funded

I was thrilled with the outcome, but more importantly, so was the executive team. They praised the process for driving clarity, spurring healthy debate, and giving them new appreciation for the data team‘s work and constraints.

Several execs even remarked that they wanted to use a similar approach for prioritizing their own teams‘ roadmaps going forward! And one came up to me afterward and said, "Seeing all those great ideas left unfunded…it‘s so clear you need more headcount. Let‘s talk about getting another data engineer or two in the budget." Music to my ears!

Tips for running your own prioritization session

Reflecting on this experience, I‘m a true believer in Pandora‘s method for prioritizing data features and aligning stakeholders. That said, there are a few things I‘d recommend keeping in mind if you decide to try it out:

1. Socialize the approach ahead of time. Make sure key stakeholders understand the mechanics of the process and the "why" behind it before throwing them into the deep end. A little context goes a long way!

2. Pick the right decision-makers. The magic really happens when you have people with cross-functional, company-wide context in the room. Avoid those with tunnel vision for their own team at all costs.

3. Keep feature pitches short and sweet. At the end of the day, you‘re just trying to get the key information across to enable apples-to-apples comparisons. Save the detailed specs and edge cases for later.

4. Anticipate (and welcome) healthy debate. If you‘ve done your job right, there will be more good ideas than you can possibly fund. Expect some spirited discussion and even disappointment – it means people are bought in!

5. Stand firm on capacity constraints. This is your chance to highlight all the behind-the-scenes work that goes into "keeping the lights on." Don‘t downplay what it really takes to deliver production-grade data products.

6. Capture the decision logic. The value of this exercise goes beyond the prioritized list. Make sure to document why certain features made the cut or didn‘t, preferably straight from the mouths of the decision-makers. You‘ll be glad you did when executing the roadmap.

7. Bring the receipts. A single prioritization session likely won‘t magically solve all your stakeholder management woes. Continue to reference the process and rationale behind roadmap decisions in your ongoing comms.

A virtuous cycle

Perhaps the biggest benefit I‘ve seen from adopting Pandora‘s method is that it kicks off a virtuous cycle.

When stakeholders have visibility into data engineering capacity and constraints, they start to adjust their expectations and engage with the data team more strategically. They still bring great ideas to the table, but they‘re more open to scoping them progressively vs. expecting the kitchen sink out of the gate.

In turn, that opens up bandwidth for the data team to work proactively with stakeholders on defining and de-risking their feature requests before prioritization sessions. Which leads to richer discussions, better scoped projects, and ultimately more predictable roadmap delivery. All of which reinforces trust on both sides.

I won‘t claim that Pandora‘s prioritization method is a silver bullet. It‘s not a substitute for strong stakeholder relationships and thoughtful roadmap planning. But in my experience, it‘s a powerful tool for facilitating those very things as a data leader.

If you‘re a fellow data professional grappling with prioritization at your company, I highly recommend giving it a shot. And I‘d love to hear how it goes – please share your experiences (good, bad and ugly!) in the comments.

Looking to learn from other data leaders and exchange best practices? Join the conversation in the Analytics Engineers Club Slack or your favorite data community. The more we can learn from each other, the better!