At Griffin, we’re building a bank. From scratch. It’s a huge, resource-intensive undertaking. From a product perspective, it requires us to be extremely thoughtful and deliberate about what we build and why. “Move fast and break things” won’t cut it here‍—‌we need to find the right balance of innovation at speed and responsible building. This is why we’ve chosen to run our company a little differently. For example:

1. Even if someone is a great fit for Griffin in terms of skills and experience, we won’t hire them if they don’t embody our core values. This is how we make sure our collective mindset stays thoughtful and deliberate as we grow.
2. Our technology stack is not mainstream. We want our internal systems to be built on immutable, event-driven architecture, which is why we chose Clojure and message logging. This choice gives us a competitive advantage in delivery velocity and also in terms of our product’s simplicity, performance, scalability, and reliability.
3. Our product development process optimises for discovery, innovation, delivery, and maintainability. This lets us focus the power of our first two differentiators (our people and our technology) towards elegantly and effectively solving our customer's pain points.

This blog post focuses on our third differentiator: our product process. You might find it interesting if you are:

• a product lead or manager who is frustrated with the lack of discovery, innovation, and delivery in your product processes.
• a designer or developer frustrated with your lack of involvement in the discovery process, lack of autonomy in the solution, or lack of time to build things you’re proud of.
• a founder or CEO who wants to see more innovation in your product and clarity in your roadmap, and to prevent burnout in your people.

"Features, Discovery, and Improvement are all first-class work, and should all be scheduled, measured, and showcased. There should always be some of each in flight."

Our product development process

At Griffin, we use Shape Up: a product process invented at Basecamp. Their former Head of Strategy, Ryan Singer, has written an excellent and approachable book that explains Shape Up in detail.

Shape Up in a nutshell

Shape Up is a dual-track process where product discovery work ("shaping") happens in parallel with product delivery work ("building").

The six-week shaping and building cycles happen in parallel. Six weeks is enough time to shape a clear "what and why" for a new feature. Six weeks is also usually enough time to figure out "how" to build and ship a shaped feature to customers.

After six weeks of shaping and building, there is a two-week "betting" period. Betting is when all the "pitches" (i.e. discovery documents from the shaping stage that are ready-to-build) get reviewed and prioritised. The winning bets are handed over to the Delivery teams, and the cycle starts again.

In parallel with betting, there’s also two weeks of “cool-down” from the last build cycle, which gives us time to wrap up any loose ends and run retrospectives.

Why we chose Shape Up

Shape Up improves on other product processes because it:

• breaks out product discovery and places it on equal footing with feature delivery.
• involves developers early in the product discovery process by encouraging them to give feedback on discovery documents while they’re being shaped.
• encourages longer iterations, with enough time to shape and ship complete features.
• encourages product experts to own the "what" and "why", and delivery experts to own the "how".
• encourages better feature slicing and early shipping of end-to-end functionality.
• sets aside dedicated "cool-down" time for technical and product debt reduction.
• explicitly acknowledges that delivery work also involves solution discovery.

"It’s in the doing of the work that we discover the work that we must do."

How we customised Shape Up to fit our needs

Shape Up was an excellent starting point for us when we began using it in early 2021. Over the past year, our retrospectives have helped us to refine and optimise how we apply the process. We decided on the following changes to by-the-book Shape Up:

• projects should be called bets
• bets should include unknowns, assumptions, and decisions
• pitches should include a glossary
• pitches should include a user story map
• pitches should include release notes
• tasks should be tracked with a kanban board

Projects should be called bets

The Shape Up book uses "bet" as the verb and "project" as the noun. We've found it more useful to use the word "bet" for both. Calling in-flight projects “bets” reminds us that each piece of work is still a gamble, even after we've started working on it.

"That’s our bet, our best guess, our belief, our hypothesis. All of those are uncomfortable words for people who believe they’re building the right thing."

Bets should include unknowns, assumptions, and decisions

When a new bet kicks off, the Delivery team enters an investigation and understanding period, i.e. the solution discovery phase.

At the start of the discovery phase, we typically have a lot of unknowns, a few assumptions, and usually no decisions. As the bet progresses, we convert unknowns into assumptions, and assumptions into decisions.

We strikethrough "solved" unknowns and assumptions, but we don't delete them. Keeping them visible gives us a clear picture of what's happening during the solution discovery phase and helps us track our evolving knowledge. It also gives the Discovery team a clear place to answer questions, confirm alignment, and help grow the Delivery team’s understanding.

"A perfect formulation of a problem is already half its solution."

Pitches should include a glossary

We've added a glossary section so the Discovery team have a dedicated place to define any new terminology that emerges from the pitch. When the bet kicks off, we transfer the glossary to the bet page, and continue tracking our developing understanding of the terminology. When the bet is complete we transfer any new terminology that will be helpful to our customers into our public documentation.

In a start-up environment, it can be difficult to keep a grip on language‍—‌acronyms and terms of art can rapidly multiply and change as our thinking evolves. A glossary helps us make sure that we all mean the same thing when we use a particular word. Locking in a shared language early in the process saves time and makes it easier for the Discovery teams to communicate the "what and why" of pitches. It also enables the Delivery teams to make sure our APIs, UIs, documentation, data model, and codebase are all clear, consistent, and maintainable.

"To communicate effectively, the code must be based on the same language used to write the requirements‍—‌the same language that the developers speak with each other and with domain experts."

Pitches should include a user story map

User story maps are an excellent tool for communicating the steps involved in a user's journey through a product. They also help to explain how a feature fits within the larger context of the product journey, which helps to paint a clearer picture of "why". Understanding the steps in the user journey can also help the Delivery team with scope slicing during kick off.

Pitches should include release notes

We decided that pitches should include release notes, written as though the feature is already complete and we’re describing it to our customers. This forces us to consider and communicate what an ideal successful outcome looks like. It also encourages a clarity of language, which helps both the Delivery team and the rest of the company understand what we're working on, and why.

When the feature is shipped, we publish the release notes from the pitch in a customer-facing change log.

Tasks should be tracked with a kanban board

We've added a kanban board to each scope in our bet template. This replaces the to-do list recommended in the Shape Up book.

We've found that kanban boards give a better visual indication of progress, and they're more satisfying to interact with than check-boxes. Plus, each task card on the board gives additional space to capture information for collaboration and coordination.

Parting thoughts

Shape Up isn't a panacea. It won't magically turn a failing company into a customer-focused delivery machine. But it is a thoughtfully crafted product process, which encourages effective team behaviours, solving the right problems, and balancing new features with debt reduction.

Our tweaks to the process have further optimised its impact for us. They've improved the handover between Discovery and Delivery, encouraging us to focus even more on cross-team alignment and customer impact.

If you're new to Shape Up, I would recommend starting with Ryan Singer’s book. If you've already started with Shape Up, but have been struggling with clarity around the pitch-to-bet kick-off handover, then give our tweaks a try. We think you'll like them!