Make it work, make it right, make it fast

At Splits we follow the engineering adage "make it work, make it right, make it fast." The order is important: first things first. Making it work, then making it right, then making it fast is the efficient way to build, which minimizes time and energy wasted building things nobody wants.

Recently we discussed sequencing as strategy: "What you learn today affects what you will do tomorrow. But if you're already tackling tomorrow's problem today, you don't have the information to solve it properly." 

"Make it work, make it right, make it fast" is sequencing as tactics. The same fundamental principle, but zoomed in. And still entwined with commitment engineering.

Commitment engineering is central because it grounds your educated guesses in tangible external signals. "Make it work, make it right, make it fast" provides structure for responding to those signals.

These pithy heuristics help guide our instincts, and we've learned a lot from putting them into practice. Here's what we've discovered during each of these phases.

Make it work#

Commitment engineering is how you earn the right to start "making it work" in the first place. Even a quick-and-dirty MVP should come after talking to customers. Are they ready to contribute to the problem-solving process? For example, by agreeing to test your first iteration live on a 30-minute call. If customers are willing to invest their own time and effort, that validates how important the problem is to them.

Next, actually "making it work" means creating a functional prototype. Writers will tell you to bang out a messy, inelegant rough draft, and only then start editing — this is the software equivalent. Importantly, this step is explicitly not "making it right." Reid Hoffman famously says, "If you're not embarrassed by the first version of your product, you've launched too late." Give yourself permission to ship something you know isn't right.

How do we scope this functional prototype in practice? Two steps: broad, then narrow. First, we make a list with everything we think might be important or relevant to the project. Then, we go through the list and aggressively descope: what is the absolute minimum from this list we can finish and have a functional prototype? Once that MVP is in front of users, we've "made it work."

When spinning up Teams, we got started fast by forking the Daimo contracts. This allowed us to iterate on the UI and contracts in parallel, significantly reducing our time to production. On the commitment engineering side, we onboarded six design partners who committed to being active alpha users. And, of course, we dogfooded aggressively.

If usage is expanding, despite the obvious flaws, and the constructive criticism is consistent in message, it is time to start "making it right."

Make it right#

You should enter this phase with lots of information about what needs to be fixed. In the best-case scenario, you're fixing edge-case bugs and polishing the UX. Other times, you're making foundational changes to the technical and visual designs.

The original version of the Splits contracts explorer had no subgraph. It pulled everything, directly from the blockchain. This was not performant, to put it lightly. Early usage kept coming anyway, which proved to us that the explorer was worth more effort. So then we added the subgraph architecture.

Today, we're firmly in the "make it right" phase across much of the Teams product. Compliance, for example, is fully disjointed from the rest of the experience. Despite the lack of polish, people use it happily, because it solves a pain point for them with onchain contractors and vendors. Accounting and Earn are in similar states: just good enough to unblock our users from completing their job-to-be-done. These features are begging to be revised and upgraded.

During "make it right" you should understand how a new feature fits into the whole. At Splits, we rely heavily on feature flags, allowing us to build features in isolation that dovetail awkwardly with the rest of the product. Once we're ready to "make it right," we can figure out how they mesh with everything else. Continuing adoption will raise the bar for each of these transitions.

As you make progress, the ratio of positive feedback to constructive criticism should dramatically shift. A key sign of rightness is when users start praising how easy, intuitive, and seamless everything feels. At that point, it's time to "make it fast."

Make it fast#

"Is this API call even necessary?" is a "make it right" question. "Let's halve the time for this API call" is "make it fast."

As a startup still striving for product-market fit, Splits has the least experience here. So we will defer to the greats:

Making "make it work…" work#

Successful products have the right shape: a form that fits the context of the market, users' motivations and constraints, etc. Happily, generating any form allows you to test against the context. Based on the results, you develop a better understanding, and the next version is a better fit.

As you've heard before, action produces information. Doing anything is better than doing nothing. However, even better than "doing anything" is doing something intentional. "Earning the right" and "make it work, make it right, make it fast" are guides that have helped Splits build more effectively.

Ship, observe, learn, hypothesize. This is a variation on the classic OODA loop:

It is essential to not just accept but embrace that the first form is flawed (or maybe entirely wrong). "As in science," Paul Graham wrote, "the hard part is not answering questions but asking them: the hard part is seeing something new that users lack." You need to run repeated experiments to test your conceptions.

To learn fast, you want a tiny OODA loop: one person talking to users, designing, shipping, and testing. Whenever possible, the "make it work" stage should be handled by a single individual. Once you reach the "make it right" phase, you've earned the right to invest more resources. At this point, team leaders should distill feedback and usage data into insights for the engineers to act on. This feedback and data is how the market pulls product out of you.

When a janky MVP that barely works is enough to attract users, you're in the right phase of market development for a small, scrappy team to have an outsize impact. It's crucial to keep the team small until you hit overwhelming growth due to product-market fit. Otherwise you slow down the building loop.

At Splits we're building institutional-grade banking that's instantly available to everyone in the world. Built on Ethereum. No account minimums, paperwork, or legal entity needed. Sign up today.