Allocating rather than Estimating: How we shape work at Wizardsardine

At Wizardsardine, we’re on a mission to make Bitcoin self-custody secure and accessible with our flagship product, Liana wallet. As with any team building complex software, we’ve wrestled with the classic problem: how do you estimate what a feature will cost before you start building it?

For a long time, we followed the traditional waterfall-style approach: define the feature, estimate it, build it… and then watch as unforeseen issues turned our carefully made estimates into moving targets. Sound familiar?

About nine months ago, we made a significant shift. Inspired by Basecamp’s Shape Up methodology, we moved to a cycle-based process that helps us make better bets, ship more predictably, and keep costs under control.

Here’s how we now shape and estimate features—before writing a single line of code—and what this approach has meant for our team and product.

From Ideas to Action: Our Cost Allocation Process

Rather than trying to predict how long a feature will take, we start by deciding how much time (and budget) we’re willing to invest in it. This shift—from estimation to allocation—has helped us make better decisions, reduce scope creep, and ship more predictably.

Here’s how our process works.

1. Collecting and Shaping Ideas

At the end of each cycle, the product manager (hi, that’s me!) gathers ideas from the team, roadmap, and feedback received during the previous weeks. The focus here is on problem framing, not detailed solutions. We try to define the objectives and main technical implications without locking in specifics too early.

2. Validating with Stakeholders

Before ideas can become candidates for the next cycle, they’re validated with both technical and business stakeholders. This avoids spending time on features that are either unfeasible or misaligned with our goals.

3. Betting and Allocation Meeting

At the end of each cycle, we meet as a team to prioritize the shaped ideas. This isn’t just a scheduling meeting — it’s a strategic bet. We decide together:

• Which ideas are worth tackling now
• How much of the team’s time (and budget) should be committed to each

To guide this process, we use a simple spreadsheet that visualizes how team time is allocated. The spreadsheet will automatically show the estimated cost of the different features, making it easier to evaluate its potential ROI.

Below you can see a sample table in which team members time are allocated. This fictional team includes:

• 2 developers, fully allocated
• A product manager, fully allocated
• An operations person, 40% allocated to the development
• A marketing & comms person, 40% allocated to the development (in terms of costs)

Total: 6 weeks per role, fully allocated.

Assuming each person costs $100,000/year, we can estimate the budgeted cost for each feature:

By giving us a clear picture of each project’s cost, this greatly helps us evaluate whether a feature is worth the bet based on expected return.

4. Clear Objectives and Kickoff

Once the bets are placed, I recap the objectives of the upcoming cycle, with explicit dates and deliverables. The cycle kicks off with task definitions and discussions about technical/design choices.

Staying in Bounds: Shipping Within the Bet

The key principle of our approach is that the deadline is fixed, not the scope.

• We identify the biggest unknowns first, tackling them early in the cycle.
• Throughout the project, the product manager and developers collaborate closely to adapt the shape of the solution and keep it within bounds.
• When needed, we reshape—cutting, simplifying, or rethinking parts of the original idea—without compromising the core value.

This is the main shift from our previous process: the time allocation for each project is not an estimate of how long it will take, but a budget—a clear limit on how much time (and money) we’re willing to spend on it.

This leads to realistic expectations, better risk control, and frequent, predictable releases.

Wrapping Up and Cooling Down

The last stretch of the cycle is reserved for testing, polishing, and release—a part often forgotten or underestimated in traditional planning. After that, we take a few days to cool down, reflect on what worked (or didn’t), and start shaping the next cycle.

Why This Works (and What We’ve Learned)

We’ve found this cycle-based approach brings several concrete benefits:

• Upfront cost visibility Estimating in team-time helps us understand the real cost of a feature—and whether it’s worth building—before we start.

• Scope control = cost control Instead of endlessly expanding scope, we commit to shipping within a timebox. This encourages smart tradeoffs, not perfectionism.

• Predictable releases Features are delivered on a consistent cadence, helping us respond to new info quickly and keep our roadmap moving.

But it’s not magic. This method requires discipline:

• Saying no to promising but risky ideas
• Letting go of “perfect” in favor of “done”
• Being honest about what’s possible in six weeks

It’s been worth it. We ship more predictably, make better bets, and spend less time arguing with the calendar.

Roadmap, Backlog, and Changing Priorities

One of the biggest shifts with our cycle-based approach has been in how we think about the future — specifically, our roadmap and backlog.

We no longer maintain a rigid roadmap or a long list of features to build over time. Instead, we keep a loose collection of ideas — things we might want to tackle eventually. Every 8 weeks, we reassess these ideas alongside new information, and decide what’s most worth building right now.

That said, we’re not flying blind. We do maintain a clear sense of direction and medium-term goals — a north star that helps us decide what ideas are worth considering. But this direction is not a strict sequence of steps. It’s flexible, and intentionally open to change as we learn more from users, market conditions, and technical work.

This change in mindset has had a surprising side effect: We’ve noticed that when a feature doesn’t make it into the current cycle because something else is more important, it often doesn’t feel as relevant in the next one. In fact, about 50% of the time, those previously “urgent” ideas either:

• Get replaced by new, higher-impact opportunities, or
• Turn out not to be necessary anymore.

This natural decay of urgency shows just how valuable it is to reassess priorities regularly. It prevents us from committing to outdated plans, helps us stay focused on what matters most today, and ensures we’re always learning — not just delivering.

Final Thoughts

At Wizardsardine, building Bitcoin products like Liana means playing the long game—but that doesn’t mean we can’t move fast. By adopting a shape-first, cycle-based approach, we’ve found a balance between strategic clarity and execution speed.

If you’re struggling with unpredictable timelines, scope creep, or unclear priorities, we highly recommend giving this approach a try.

Want to know more about how we build Liana? Reach out or follow us on X.