A Little Goes a Long Way

When kicking off a major software project, it pays to start small.

In the world of business, most of us have been conditioned to believe we should be making a bigger impact, aiming for a bigger goal, striving for a bigger salary. “Bigger is better” has been the mantra of the developed economies since the 1950s. Size equates to momentum.

In the technology industry, this phenomenon is amplified. The tech giants have more cash than many large countries, the landscape is overrun with herds of once-rare unicorns, and hardly a week goes by without a chest-thumping entrepreneur claiming to have created “the Netflix of [insert mundane everyday object here]”.

But is bigger really better? Well, not always. In fact, size can sometimes be the enemy of success.

At Smudge, we work with a lot of large businesses to help them solve complex problems with technology. That complexity is often intensified by the internal politics of the customer organisation, including entrenched opinions, risk aversion and loss aversion. In large enterprises, meaningful change can take years, even when it’s the right thing to do.

As an external technology partner, we are expected to manoeuvre through this obstacle course of emotion without setting off too many cultural booby traps. You might wonder who in their right mind would repeatedly wade into this quagmire.

Fortunately, we’ve become quite adept at charting a course through the chaos. And one important lesson we’ve learned along the way is no matter how large the organisation or how amorphous the problem, it pays to start small.

Mighty Oaks From Little Acorns Grow

When kicking off a major software project, one of the most common temptations for a large enterprise is to throw people at the problem. However, when it comes to early-stage product development, this just doesn’t work.

If you haven’t figured out the recipe, you don’t want too many cooks in the kitchen. In fact, to start with, you might not know whether you’re making an appetizer, an entrée or a dessert.

Even if a customer has significant in-house resources, we recommend dedicating only one or two individuals to a project to start with (often someone from Smudge working with a partner from the customer side). These pioneers should ideally be generalists who have a broad skill set, including field research, UX/UI and development.

The Power of Generalists

Working in a ringfenced environment, where fragile ideas are protected from pre-existing bias, generalists can quickly create an unpolished prototype that can be tested with a small number of users.

Based on real-world feedback, they iterate the solution until they’re sure it meets the original intentions. If not, they revisit the problem and/or solution, and continue iterating.

At this point, assuming the project is not secret, there will likely be specialists within the customer organisation with their noses pressed against the window, glaring with a mix of envy and disapproval at the seemingly underqualified generalists who are not applying the rigour that comes from years of training in a particular discipline.

The reality is that bringing in specialists too early can put focus in the wrong areas and/or waste valuable time; for instance over-engineering a feature that’s not eventually needed, or over-thinking a design element that will be overhauled many times before a product ships.

Experts think inside the box, whereas a generalist uses tools in ways they are “not supposed” to be used, which can result in new approaches to problem-solving. A generalist sees things that a specialist doesn’t.

Starting small is not revolutionary. The idea of a “MVP” (Minimum Viable Product) has become gospel in startup land, and it’s worth remembering that many of the most popular and important products and companies of our time started out tiny. Facebook was born in a dorm room. Apple, Google and Amazon were founded in garages.

In fact, some of these companies continued to espouse this approach long after they got big. In his excellent book Creative Selection, former Apple software engineer Ken Kocienda describes how a three-man team bootstrapped the original Safari web browser by carefully choosing the most appropriate “combination of important / passable / ignorable features” early in the project.

At Smudge, starting small gives us the flexibility to adjust scope or resources as a project evolves, or as we unearth new problems and use cases. Working hand-in-glove with a customer, we can establish whether a solution is maximising value for users by heading into the field to get insights, and course-correct accordingly.

Once we have clear direction on where a project is headed, we finally bring specialists into the mix. By this point, we are building out the feature set, polishing the experience and sprinting full speed towards a major release.

If a project survives this long, the role of the external technology partner has evolved from that of skunkworks revolutionary to cross-functional stitcher. Now a key goal is to build trust across the wider customer organisation, win over the previously affronted naysayers, and connect people and departments who may historically have been siloed - or even competitive - but are now required to work together for the benefit of the user.

The good news: by this point we have a far better view of how the solution will be used and how the project is likely to play out over the longer-term. All because we started small. After all, a little goes a long way.

Imported Layers Created with Sketch.