The Sandbox

We have learned how to do this job by doing it. And we’ve been doing it for over a decade.

We have learned quite a few lessons along the way, and over the course of the last year, we have put a little more effort into sharing them with you guys. When you’ve been so busy over the course of thirteen years building products, you run the risk of not prioritising who gets to see the work and enjoy it. The products are out there in the world, the companies are thriving, the clients get to enjoy them, and it’s all as it should be.

However!

While we meddle in all kinds of tech (we love problems, we fall in love with challenges all the time), Web3 has been our bread and butter for years. We have developed a very significant level of expertise in the area. Every scene has its weaknesses, and putting product over hype has never exactly been a strength for crypto and blockchain. We’d like to believe we’ve figured out how to do at least some of the things that help a company be successful within that framework. How to work within the hype cycles, how to ride out the bear markets, how to build real things that people enjoy using, instead of never-ending fodder for Twitter and Telegram discourse.

We have come to call our method (it’s a loosely used term) our Sandbox. Here are some principles that help ensure it works more often than not.

Everyone makes wrong bets. That’s how it works. We’d rather not spend six weeks building something that will never see the light of day. This is how the world works for startups, and why so many of them fail, and that’s fine.

Make small batches of cookies and try the recipes out. Make small bets, see how the users react. Learn quickly.

AI tooling has helped us run this process much faster than in the past. We’ve been validating assumptions literally the day after having a couple of work sessions with a client. A Subvisual designer can now quickly sketch a lo-fi of the outcomes of that session (typically diagrams), and a single dev is now able to come up with something we can test.

The way we run our Sandbox introduces testing and early feedback earlier than the market would allow. This is by design. We are playing for time. We want you to break as much stuff as you can before the stuff you have to break will break you. That sentence makes sense, we double-checked.

Here’s a story about a hospital and how failing quickly can matter:

We were once asked to build productivity tooling for a hospital. In the very first meeting, our client explained a number of issues they were facing, most of them relatively simple to fix, more to do with organizational principles than anything else. We didn’t expect all hospitals to be facing these problems, though our client was convinced they did.

The first thing we asked him to do was to validate his assumptions. Ask around. Get in touch with colleagues and other potential users for the product. Ask them if they felt the same pains and would welcome the same solutions. He did. He quickly learned that his assumptions were wrong and his issues were unique because everyone else had already solved them.

The project was dead before it began, and sometimes that’s the best outcome for everyone.

Which leads me to the next point:

Builders are great and we love them. I work with devs and founders every day, and they’re always the ones driving innovation. But they need their assumptions stress-tested. One key element of our Sandbox is figuring out which questions to ask, and we’ve become quite good at this.

Figure out what your assumptions are. Anything that you take for granted, even if it’s backed by data. What your use cases are, how users will approach the product, what problem is it solving, why is it solving it efficiently. Now, test. Stress test. Assume everything will go wrong in every possible way. It’s a common problem that founders base their whole thesis on “facts” that are in fact assumptions or well-informed assumptions at best. When left unchecked, more often than not, those “facts” come back to haunt them.

Let’s say you want to disrupt the rental market, and your market research tells you landlords want more information about potential tenants. They want to know credit scores, some basic data about potential people who will live in their properties. Let’s say your solution is to build a marketplace where potential tenants have detailed verified profiles.

We decided to stress test this, and guess what we’ve learned? Potential tenants have absolutely no interest in sharing information about themselves unless they get information back from landlords, which landlords are very reluctant to do.

The prototype was not ready to go into deployment. Based on the information we gathered from interviews with prospective tenants, we understood they required data landlords consider sensitive, such as how much closer it would bring them to a deal and how other tenants rated the landlord in the past. We needed to figure out how to incentivise landlords to provide this, something we weren’t even sure we could do. Asking these kinds of questions at the right stage can make or break a startup and keep you from going into fruitless rabbit holes.

This is as much art as it is science, but it is important.

Next up: extending the logic to all other teams. Stress test your market assumptions, your tech assumptions, your model assumptions.

What does done look like?

You need a lightweight project template. It can grow into a more complex solution months in, but you need to have something that is clear to everyone from the get-go. It’s fine to follow instincts and adapt to every client and project, but decision processes – who makes them, when they’re made, why they were made – need to not be a hindrance.

Decisions are a wonderful thing. We love decisions. We think people tend to delay making them too much, not make enough of them, and be too afraid to change them.

That being said, decisions only have a point if they’re consequential. Once you’ve made a decision, your team needs to follow through. That can’t and won’t happen unless everyone is on the same page. Clear distinctions between what jobs need to be done, what jobs need to be iterated, what’s on hold, and prioritized next-step plans are not just things you should have, they’re things you should have available and updated all the time.

This will inevitably lead to rituals, and rituals are good. We tend to plan ahead for two-week periods and review. Progress needs to be visible, and the team needs predictability. Having a sense of pace also helps you better estimate what’s realistic. After every two weeks, we tend to do a show-and-tell, so everyone knows where everyone is.

We don’t often recommend books on this blog, but here’s an exception.

Every project is different and every founding team is different. Some companies like having daily standup sessions. Some are agile. Some like to go on hikes for team building.

We won’t tell you how to organise your rituals unless you ask for help, but we do believe in the importance of setting aside specific times for the team to come together and share progress.

Progress needing to be visible doesn’t necessarily mean using Jira, it doesn’t mean doubling everyone’s work and three-week onboarding hassles. You can adapt, make something light that works for you. We’ve distilled the minimum requirements for a healthy project pipeline, and we use it to kickstart our projects. This has proven to be more than enough for the first few months and allows us to evolve organically as needs increase.

Here’s a template. Feel free to check it out.

But do keep in mind: if it’s not visible, you are creating incentives for progress not to happen. This is a good time to mention company culture as well. Shaping company culture is particularly important in the early stages, because this is not something that’s easy to fix.

We work with all kinds of teams on all kinds of projects. We’ve led design-first projects, where we essentially only worked on UI and UX. We’ve worked on deep tech, fintech, crypto rails, global railways for stablecoins. We’ve worked on Web2 projects. We’ve developed cute little apps for hackathons that had us recording sound in a public toilet (this is a true story). We have helped some very large companies build products that are used by tens of thousands of people every day.

We’ve integrated large teams and then hired our own replacements. A perk of working with us is a product-first culture. We will help you think critically about what you’re building, not just execute. After we leave, your team will be shaped according to your needs, but you’ll have a real self-sustainable company.

We aren’t contractors. We’ve built the companies alongside the products, shaped by our clients.

You can’t do any of this if you only know one way of working. Companies that have worked with us don’t necessarily work like us. But you also can’t do this job if you don’t have solid first principles that will guide your hand. Even years after we’ve left companies, we recognise a little bit of our work in what they’ve built.

This is the best it’s ever been to build products. We are at a stage of maturity, and AI tooling has gotten to a place where we can do things better and faster than ever before.

We still have some slots available for next year. If any of this resonates with you, get in touch.