Setting Scope and Building Incrementally

What is incremental development in product? And why does it matter so much?

👋 Hi, I'm Jaryd. Welcome to this weeks Slice — the free weekly newsletter about product, startups, growth and working with people.

If you’re not as subscriber already, join below. It’s free. 👇

If you enjoy this newsletter, and know someone else who also might, you can share it below👇

Share The Product Slice

What and Why

As a PM, you're going to be evaluated on the successful products that you launch. The key word there is Launch. If something hasn't shipped and is being developed still, it's not contributing any value to customers, the business, or your career. This means prolonged development times where products are being built without any real users and feedback kills extremely valuable learning cycles and the opportunity to be getting traction. 

In the early days of my first startup (and my first time working on product) when we were just starting development, I made the mistake of failing to scope correctly. I had a long list of features I wanted included and was so excited that this dream-product would come to market that I said “yes” to all of them as requirements, squeezing everything into V1. In short, this colossal mistake led to it taking much longer than planned for the first functioning product to get released, higher costs, and a major missed opportunity for us to have people using it and giving feedback. We ended up having to rebuild a lot of things and go backwards before we could go forwards again.  This was a key learning moment about the importance of setting scope correctly. 

Fast forward a few years, and one of the first pieces of advice I got from my manager and mentor during onboarding was this: It's much easier to go forwards than it is to go backwards. You don’t want to be taking things away from your users. And that, in a nutshell, is the importance of setting scope and incremental development. 

Scoping is the careful process of choosing what to include and exclude from a milestone or a release target. It's an important skill in prioritization and balance that not only requires you to decide on “what” is being done, but equally as important, “when" it should be released. The faster you want to ship something, the less work you can include. Each of those variables therefore directly influences each other, and as a PM it's finding the right balance between getting something released as quickly as possible , and also only releasing something that has enough to be usable and add value.

The below is a very popular philosophical visualization of what incremental development is – where at each step, something of value is delivered to customers and learnings from that are taken into account for the next iteration which is a more fleshed out product.  That is the good takeaway from this example.

I have a critique of this example above -- the increments don’t add value on top of a previous increment, rather they are replacing one feature with another. Each delivery is a stand-alone product, and while each increment does solve the problem of moving faster, each one also addresses its own need. A car and a bicycle satisfy different needs and wants, and both of those products fit into their own large and unique markets. If you were the PM for this product line, and each step was a milestone, your team would be losing faith in you and getting frustrated, because the engineering and design needed to make a motorbike is totally different to a car, and would just depreciate prior work.

Let's take an accommodation booking site like Airbnb as an example, and look at how incremental development plays out in its simplest for, starting with an MVP towards a more valuable version of the same product that solves the same key problem. 

  1. Start with the ability for a host to list a location. Having a supply of places to stay at is the most important thing. Start here. 

  2. Then give travelers the ability to search for a place to stay by  location and send a message to the host. Now that you have some places to stay at available, allow people who need them to book them.

  3. Then give travelers the ability to pay for a stay through your site. You get feedback that paying is a major pain point for your users.

  4. Then make it easier for travelers to search for places by improving your search filters. You get feedback that searching by location isn't enough and other things matter to travelers. 

  5. Then give both hosts and travelers the ability to leave reviews. You realize that interpersonal trust is very important in your marketplace.

  6. Etc

Even if you knew from the beginning that the end-user would want all of these things that you've build across 5-steps, you want to break that scope up, start as small as you can, and continue building towards that end-state as fast as you can while always accounting for feedback from real users. 

Hypothesis-driven milestones 

Building incrementally isn't just about taking a larger outcome and slicing it up into smaller chunks of work. It's about validated learning, where what you learn from end-users at each increment is evidence-based and actionable, leading to genuine product improvements in each iteration. 

Each iteration should start with a hypothesis. In order to measure what you've built and figure out if you're on the right track or not, you have to know what you're hoping to achieve. Your hypothesis tells you what you're testing against. 

After you deliver an iteration to people, look at your data and speak to your end-users.  This is where you gather your learnings, and get ideas around what should be adding to your next build cycle (sprint or milestone). 

This is the validated learning loop. 

Communicate scope and releases 

As a PM a key part of your job is communication, and making sure you're updating the right people about project timelines, deliverables, and ensuring peoples expectations are managed. 

Once you've got an idea of your projects scope and release points, make sure the right people are aware of that and you have buy-in before you actually start engineering work. 

When you present your recommended approach to your team, make sure to cover why you're suggesting you go about it this way, and perhaps any alternative approaches you considered. This shows you've put in the work and helps you get that buy-in you need.

Be aware of scope creep 

Scope creep is when you decide to allow extra features and functionality into a milestone or increment of work. 

These things could be necessary and valuable, but you need to ask yourself if it's essential that they get done now and in this iteration. Even if it's a small feature or something marketing has asked you nicely to please include for them, you need to able able to say no to the unnecessary and distractions. 

Whenever you added something to your scope, the following always happens.

  • You increase the cost 

  • You add more time 

  • You add more effort for your team

  • You need more resources 

Managing scope is knowing when to add something, and when not too. There are definitely times when you need to push something into your scope, and having a “nothing gets through” mentality about scope is risky. 

When you have your scope planned out, review it again and cut out anything unnecessary. Less is often more here.

Leave a comment

Every week, I write about product, startups, growth, working with people, and anything else that I’ve found helps me have a happier and more meaningful career in product management

If you’re not as subscriber already, join below. It’s free. 👇

If you enjoy this newsletter, and know someone else who also might, you can share it below👇