NOTE: This post was originally published in an older version of the blog. While all efforts were made in the migration to ensure the links still work and other visual elements communicate the intended meaning, some issues may remain. If you identify any, please drop me a note and I'll get it fixed asap.
blog-details-image

3 Startup Software Superpowers - Part 1 - Introduction

February 25, 2022

Software Engineering, Startups, Product

One of the awesome things about working in a startup is that you get to take on an enormously diverse range of tasks. But how do you ensure you're delivering high quality work across all of them?

I love experiencing the full lifecycle of a product. When it's just you and a small team taking an idea from initial concept through design, planning, implementation, sales and operations you get to wear a lot of hats (or capes?) - something that can be immensely rewarding.

A lady's head, wearing a yellow hat, a nurse's hat, a police officer's hat, a chef's hat and a student's cap.
Working in a startup, you get to wear a lot of hats!

Over the years I've learnt three conceptual tools that have helped me be effective at different stages of the journey. I'll go further: they are like having superpowers. Once you learn and apply them, you'll feel like a superhero too!

In this series of posts we'll take a look at these superpowers and demonstrate how to make the most of them in a startup context.

Part 1 (this post) will briefly introduce the ideas, explain why they feel like having superpowers, and share links to other online resources with more details. Parts 2, 3 & 4 will take a deeper dive into each as we go on the journey of our fictional startup.

They are:

  1. The Concepting & Design Superpower
  2. The Planning Superpower
  3. The Software Development Superpower

Our 'Super' Startup

If you're starting work on software for a startup, I'm assuming you and your partners already have a business idea.

To illustrate these superpowers, let's get to work for our fictional startup - and since we're talking about superpowers, and inspired by the recent flooding in northern NSW, lets build a product for some real-world super-heroes - the volunteers getting involved to help out those affected.

Our startup is codename E.A.S. - Emergency Alert System.

Superhero figure above the E.A.S. acronym.
E.A.S. - Emergency Alert System

Our mission is help co-ordinate response efforts when disaster strikes:

  1. Members of the public want to request help, and get alerts about nearby incidents so they can steer clear.
  2. Response volunteers want to find out about people who need help so that they can attend and assist.

Future expansion might include an integration with Waze to help route traffic around incidents and an integration channels to support formal government emergency services.

With the scene set, time to launch our startup!

The Concepting & Design Superpower

As the technical co-founder of E.A.S., the first question you're probably asking yourself is: what do you build to make that idea a reality?

The concepting and design superpower is known as Event Storming and when you're first working out what's needed, this superpower will save the day.

Event Storming was invented by Alberto Brandolini as a way to foster collaborative domain modelling in organisations with isolation between IT and other parts of the business, such as customer support, sales and management. Over the years it has expanded, and is now frequently used in a range of scenarios, including envisioning a startup ecosystem.

Whiteboard with coloured sticky notes on it in an event storming pattern.
Event Storming In Action

Event Storming is a startup superpower because of how well it helps you and your stakeholders collaboratively explore the uncharted landscape. It rapidly establishes a shared vision of what your system will do ensuring you're all in sync and can move quickly.

Event storming follows a fairly simple process:

  1. Identify all the 'events' that occur in your system. E.g. for E.A.S. we might have:
    1. Help Requested
    2. Help Arrived
  2. Get agreement on the time sequencing of events
  3. Work out what causes the events - user interactions? Integrations? Time-based workflow?
  4. Re-organise around key objects/entities (known as aggregates)

The result is an your starting model - one that is closely aligned with the language and domain of your stakeholders.

In Part 2 of this series, we'll follow this process for E.A.S., but if you want to check out some real life event storming now, there are great examples all over the web, like this article and these videos.

The really hard part is that in a startup, you don't know what's coming next - startups are all about exploring and learning, so you have to be prepared to evolve and iterate your ideas as you go - and that's where the other superpowers come in.

The Planning Superpower

Once you have an vision of what to build, you need a plan for building it. Unsurprisingly this is where many projects go off the rails.

The two most common mistakes are:

  1. Doing a huge amount of up front planning trying to schedule the whole project.
  2. Just getting started without planning ahead at all.

Put that way, it's obvious that success lies somewhere in the middle. This is where the planning superpower, known as User Story Mapping shines.

It's a startup superpower that helps you make the most of your initial investment by launching quickly, learning & iterating so you can rapidly find product market fit.

The genius of User Story Mapping is that guides you to plan just enough to implement a true MVP (Minimum Viable Product) --- that is, one that is both minimum AND viable. (Many folks miss one part or the other!)

For example, with E.A.S. you may be so focussed on minimum that you spend too much time on the general public requesting help, but not enough on volunteers responding. Your MVP will fall flat, as it doesn't deliver value - it's not viable.

Or, you might be so intent on viable that you lose focus on who the MVP is for. You spend a lot of time on features (e.g. a Waze integration) that your first customers don't care about, wasting time before you can launch - it's not minimum.

Diagram of a user story map illustrating elements, no content.
User Story Mapping helps you find your MVP

In Part 3 of this series we'll produce a user story map for E.A.S., but if you'd like to read more now, the first article by its creator Jeff Patton is a very clear explanation.

After user story mapping your concept, you have a realistic plan for incrementally building, with plenty of opportunities to incorporate lessons learnt.

Now how do you build the software so that you can rapidly respond to all the twists and turns that lie ahead?

The Software Development Superpower

The software development superpower is one that many have heard of, but less frequently used: Test Driven Development (TDD).

If you're familiar with TDD, you may be surprised I recommend it for startups. There is a perception that TDD is only useful if you have stable requirements, or only doable if you have the luxury of time and capital to spend writing tests.

Neither sound like the dynamic, exploratory, fast-paced world of startups.

And in my experience, neither could be further from the truth.

If you're not familiar with TDD, it's the practice of building software in very small cycles, each cycle consisting of three steps:

  1. Write a failing test
  2. Make the test pass in the simplest way you can
  3. Refactor to improve your code & design while keeping all tests passing

This is often visualised as Red -> Green -> Refactor - a familiar loop I included in my logo because I find it so valuable!

The Dev Cycles Logo
The inner cycle of the site logo represents TDD

It's a simple idea, but hard to grasp the implications of until you've given it a try. Dave Farley has a great video demonstrating the technique for beginners. Kent Beck originally developed the idea and wrote the seminal book on the topic. GeePaw Hill is also well worth following for excellent advice and content.

There are many positive benefits of TDD, but in a startup context the most important one is that it allows you to continuously refactor.

The early days of a startup are when your design is most likely to need to change/evolve rapidly. By ensuring you diligently refactor during each TDD cycle, you will find your code absorbs these changes more easily - and you will have high confidence that you haven't broken anything that your early customers are relying on.

This is important because your early customers are the ones you need to impress the most - both by delivering a reliable service, and by demonstrating that you are listening closely to their feedback.

If Part 4 of this series, I'll illustrate some key refactoring efforts the E.A.S. developers need to make and the impact of TDD.

Summary

If you want to be a startup superhero try out these tools:

  1. Event storming to explore an initial concept and design
  2. User Story Mapping to find the MVP
  3. Test Driven Development to keep your implementation moving quickly

Even if you're not in a startup, these tools are well worth learning. They are superpowers in many situations; this blog post just focusses on their application for startups.

What are your Superpowers?

This is not an exhaustive list of software superpowers by any means!

What are yours? Share them in the comments below, on my Twitter or LinkedIn

Getting your Superpowers

If you'd like to experience what it feels like to have these superpowers, send me a message - I offer workshops & training in all the above topics and would love to share my experience with you.