Is It Scrappy, or Is It Under-Engineered?

Engineering at at early-stage startup comes with some of the hardest tradeoffs you'll have to deal with in the field. While you never have enough resources to do everything you want, the more mature and stable a company gets, the longer the horizon on new feature development can (and often has to) be. In those early days, though, an extra month can be critical. Deciding how and when to spend more time than you absolutely have to is a challenge you'll face almost every day.

It's why, when discussing how to approach new features, we often lean on the word scrappy to describe how we might need to build it. Everything about an early-stage company is scrappy, because even if you had infinite resources, you often don't yet know what your needs will be in six months as you explore the market, understand how people use your product, and see how your competitors evolve. You don't work on rigid, complex operational processes because you might need to rapidly change them. You don't engineer carefully future-proofed systems for the same reason: those first steps into a feature space are likely to teach you that the future you proofed against isn't the timeline you're actually in.

That doesn't mean that scrappy systems have to poorly designed. A minimum viable product doesn't have to be unviable in the next iteration. Nor should they be. The question is, "How do I know what's good-scrappy and what's going to bite me later?"

Let's Roadmap

You're about to kick off a new project, one that's going to add a new feature path into your system. You have something you know you need now, an iteration of the feature that's exactly the unlock your business needs. You also have an idea of how you want to evolve that feature over the next year, additional automations and options that would turn a successful feature into a sustainable one. You're very certain in what you need today, but that year horizon is a little more theoretical. It depends on how this feature works out, what other changes happen in the market, and if you learn that what you already built may be enough for longer than you expected.

Product and engineering partner up, and come up with a few possible approaches to the problem, considering where it's likely to go in the next twelve months. They come back with three options:

• An extremely minimal version of the feature that will take 2 weeks to build.
• A different approach that's more robust and solves more edge cases, but will take 4 weeks.
• An approach that continues to build from initial feature through the full, long-term need that would take 8 weeks, all in.

Looking at this, it could be easy to say, "Let's go with the 2 week option. We can learn from it faster, and move forward from there." Sometimes that would be right. But sometimes? Sometimes that's going to cause problems where the 4-week choice would have been just right. In other cases, that 4-week option won't get you anything extra, it really is just an extra 2 weeks for nothing.

The difference between Over-Engineered,  Under-Engineered, and Just-Right-Scrappy isn't something you can identify just by the amount of time a feature will take. Unfortunately, a lot of prioritization discussions stop right there, on both the business and the engineering side. The business sees the extra time without immediate product benefits and wants the smallest option, and the engineering team sees the edge cases not covered by the bare minimum and wants to ensure they're closed off before launch.

Time-to-build and gaps in edge-case coverage alone obscure the conversation you really need to be having, and that's what the trade-offs are between your choices. Let's use this example to go a bit deeper.

If you feel kinda mostly good that something in the direction of that 8-week full build is where you'll need to be in a year, one question to answer is what the paths are between the 2-week or 4-week options and that full feature set.

It's common that the most minimal build means creating things that cannot get you to the full feature, but the slightly more robust version will. What that means is that you can get a feature quickly, but you aren't any closer to the sustainable version of that feature. In other words, it'll take you 2 weeks to launch, but then it'll take another full 8 weeks to get to that future state, because much of the work needs to be rebuilt while not breaking while you already have. On the other hand, that 4-week build might be a legitimate iteration towards the sustainable version. It's an extra 2 weeks now, but it's 4 fewer weeks to finish the work through the rest of the year.

On the other hand, maybe they're both steps that are directionally correct to get to that end state, and the primary difference is that the 2-week version is just super simplistic and won't work in as many situations. The question then is to determine how often those situations come up, what you'll do when they happen, and whether the cost of that (in engineering support time, in customer service inefficiency, in customers you can't serve) is worth learning more rapidly or getting to market faster.

The lesson? Time to build only tells you what something will cost, not what the work is worth over the coming months. Digging into that, into what you get for your investment and whether that investment will grow or be a dead end, is key to building the right thing.

Features vs. Capabilities

Thinking about trade-offs will get you part of the way there, but truly turning around how you think about whether your choices are scrappy or broken is to understand the difference between features and capabilities.

A feature is a thing, usually a single, discrete thing. It's a form that lets you upload a picture, a button that kicks off a job, an option in a dropdown that opens a box that lets you search records. Requests to product are often framed around what feature is needed, because not having the feature is the thing users notice and what you notice is what you ask for. Building a feature only gets you just that, though: one feature. It often doesn't enable another feature, or make building more features easier. You get what you asked for. You get a button.

Sometimes a button really is what you need, but more often, you're asking for a button because your business has a problem and it needs to get better and better at solving that problem over the next year. This is why product managers and engineers will often, when asked for a button, respond with their own question: "What problem are we trying to solve?"

Identifying the problem is important, but when you pull that thread, what it often says about how to build is even more critical. The problem may describe a business domain that will need many related features over time, incremental improvements and experiments followed by more improvements. In those cases, you may not need a feature. You may be asking for a capability.

Consider this: your business is about to sign a partnership with a company that will bring you customers, but that partnership needs to be supported by your application. You may ask for just that: a landing page for customers sent by this partner to be deemed eligible, and onboard onto your product.

But! Are you looking to onboard one partnership for all time, or at you looking to be able to onboard new partners incrementally over the coming months and years? If you really are only going to have one partner for a very long time (or if this is an experiment and you may not have any partnerships in the future), then the feature approach – a bespoke landing page for one partner may be just the ticket. If, on the other hand, this is a new direction for your business you expect to expand and support, what you're really asking for is a new capability in your system to support customers sent to us from outside partners, and the ability to onboard those new partners as deals are signed.

Knowing you need a capability doesn't mean you have to build every nuance of that capability up front. But it does tell you what success for this capability will mean over time, and that tells you how to weigh trade-offs in how much to build, when to build that how much, and what the sign is that you need to build more. Identifying that what you need is a capability – e.g. onboarding new partners within 3 weeks of signing a new deal – lets you go into the estimation exercise I described above. You can identify your options, weigh the barest, fastest feature against more robust builds, and understand what it means for your long term goals. It means you can build something that adds long-term value to what kind of business you want to take on and not simply do one thing, today, and have to redo that thing tomorrow.

Scrappy can be good. Scrappy can be just what you need. Be scrappy, but be scrappy in a way where you know not just what you're getting today, but what you may not get tomorrow. It's okay – hell, it's really important – to be okay with not being able to get some things tomorrow. That's how we stay focused on what's most important. The trick, the goal, is to not be surprised when you aren't able to get it. Weighing your trade-offs, knowing what those trade-offs mean, and moving forward from there is how you get there.

_{Feature Image by rawpixel.com on Freepik}