A scope tug-of-war

Most people don’t realize how small we are. We don’t have a group of engineers or dedicated client support. We don’t have “ambassadors” or interns. There are only two of us building and maintaining Smashrun full time, and a third who’s trying to balance a full time job with our startup, which means that we have to be ruthless about scope.

Ideas are plentiful and it’s easy to get excited about a new idea! If we had a forum, I bet “Suggest a new feature” would be the most popular section.

All new features are at the tip of something big

On the surface, a lot of things might seem simple enough to implement, but there’s always unforeseen overhead costs that go hand in hand with developing new features and improving existing ones. When features are closely tied to one another and, when there are a lot of interdependencies, it gets tricky whenever you build new things on top of it.

From a design perspective, I have to constantly make room for new additions, swap out unpopular sections of an existing page, or create an entirely new interface that is expected to grow into something larger.

• When you make room for something, inevitably, you’re making a decision to emphasize this new addition over an existing feature.
• When you swap out existing features, you’re at risk of upsetting the small group of users that still use that functionality.
• When you create an entirely new interface, you have to ensure that it’s discoverable, learnable, and usable.

From a technical perspective, if there’s new data that we’re importing, we have to figure out how we store it, in what form, how we retrieve it, and how we display it.

There’s also a more prominent multiplier effect when working with numbers. If the cost of delivering a particular feature is something like:

(x # of variables) times (y # of runs) raised to the nth power of number of users

…we’d have to seriously think hard about our server costs or spend even more time (than the crazy amount of time we already do) thinking about performance optimization.

This led to our development principles

Every time we’re on the fence about adding something, every time some new tech catches our attention, or a new suggestion pops up in our inbox, we go back to these guideposts:

Minimize Noise
– Noise is unnecessary information.

Manage Attention
– Users only have so much bandwidth. Every decision to emphasize one thing is at the expense of something else.

Try to Extend Before Branching Out
– Build on top of something vs. creating something entirely new.

Weigh Support Costs Before Building
– Consider ongoing maintenance and 3rd-party dependencies.

Understand the Target Demographic Before Building the Feature
– We’re not our customer, but saying ‘yes’ should be an informed decision.

Features providing a social good should be accessible to all users
– Paid features should essentially support the development of features that benefits the largest number of users in the biggest possible way.

With these in mind, we’ve gotten better at this tug-of-war. I certainly have. The drawing board has gotten much bigger, but there’s something kind of fun about understanding the scope of something from ideation to design to testing and implementation.

I imagine a silly giant iceberg and ask how far down the base we’re going in order to build something new. If we’re heading too far under water, it’s probably worth shelving for now to revisit at another time.