Keep it small stupid

SED_wall_1920x1200

A big part of my role at ManyWho is product management. Having worked for and run various startups, and having been a product management executive at Salesforce, I’ve learned a lot about managing change. And one thing has become very clear (particularly in cloud computing):

Make small changes often, rather than big changes infrequently.

Here are a few lessons behind that thinking. I don’t think they just apply to software and software products, but that’s my background!

1. Getting to an MVP (minimum viable product)

Many people in the software industry talk about getting to a MVP. But there’s more behind the MVP than just having one. Often you have an M, then a P, then a V in Agile development. And until you’ve got all 3, it’s extremely challenging to test your MVP:

M: You get to the Minimum release by quickly agreeing on the first set of features. You can be guaranteed you’ll forget things, won’t fully understand the depth of what you’re attempting to achieve, etc. You basically have a minimal “thing” that will teach you a lot of lessons about what V and P actually are. But you need to deliver early and often to get to your M – particularly in teams. You need to learn quickly and apply those learnings fast. The last thing you want to be doing is overly specifying the “unknown unknowns” (thanks Donald).

P: You get to the Product release in exactly the same way, but this time, you likely have a much clearer understanding of what a minimal product actually is – from your perspective. At this stage, your product, isn’t very much at all – but what it is – is the seed of what will hopefully be a super impressive offering to your customers! But more likely than not, it’s not viable yet – you’re just getting to grips with the enormity of your idea.

V: You can only really understand the Viability of your minimum product by testing on a few friendly customers and quickly getting feedback. Until you have the basic “happiness” with your V, there’s not a lot of point pushing your creation out the door to a broader audience. There are no clear lines here, but until you’re very pragmatically happy with the viability of your product, you can’t really do proper customer testing. Only you will know when that line is crossed.

Critically – every part of this is about small releases, small incremental change and fast paced movement on requirements/viability. You simply don’t have time to mess about with up-front requirements documents – they’re pointless.

2. Moving to the FVP (fully viable product)

Once you have an MVP, you’re hopefully in good hands: the hands of your customers! But get ready, because this is no cake walk:

Fires everywhere…

As you test out your concept of viability with your customers’ definition of viable, there can be a lot of problems. Lots of gaps, lots of bugs, holes, issues, you name it. Do your product principles even stack up? Do they actually make any sense whatsoever to anyone but you! This can be a stressful time – and it certainly helps if you’ve been in a particular industry for a long time. For ManyWho, we missed many of the typical start-up fires because in many ways, we were never a startup. We’ve been working in the workflow platform space for 20 years and all of that experience has been applied to our platform. But regardless of your experience – it will be small and frequent patching and change that will get you out of this. Cool calm heads and strong product leadership – you need to know where you’re going as much as possible.

… to the cooling core

Assuming you make it through the raging fires, you’ll likely have a very strong sense of product focus. Your ideas will have cemented and you’ll have battle tested your principles and methodology. You have a product. And it’s not minimum-ly viable, it’s seriously hardened. What I’ve noticed through this phase is that small changes get easier and confidence levels get much higher as the impact of change affects a smaller and smaller group of customers. The core is solidifying – and your product often gets much harder to break. Not only by customers, but by your own engineering group. It’s one of the reasons you need to keep cool and calm during the fires – you need to keep your eye on the architecture as it will significantly accelerate your path to a “cool core”. Large architectural shifts are hard (on customers mainly) – small, but frequent refactoring changes are far easier, and I believe it takes less time to reach the end goal.

3. The product market shift

Rather ironically, cloud computing has a problem if not managed using small frequent change. The problem? Upgrading and larger change is actually very hard! Once you’ve battle hardened your product and you’re in a cycle of incremental change, everything is fine. But when you need to make a shift that’s not due to technology, but rather market, it can become very hard to manage. It becomes hard because market shifts in product often result in needing to do pretty big change to the core – that wonderfully stable piece of your product everyone in engineering treats with extreme caution!

With on-premise solutions, it’s easy. You basically break everything and get your customer to figure it out 🙂 You likely need consultants to help you manage the upgrade process as it’s not a small piece of work. Just look at how Siebel, Oracle, SAP and Microsoft handle upgrades to their applications. It’s SERIOUSLY painful. However, for the vendor, it’s fine. You can incrementally upgrade each customer individually – learn from each and apply service packs as you go. It’s a gradual shift. With cloud, unfortunately, it’s all BIG BANG! Everyone goes over at once… yikes!

So once again, you can probably see the value of small, frequent change. Combined with strong product vision and market focus, you can keep a product up-to-date with market shifts. You’re iterating there constantly.

You can see that with some of the older cloud vendors with long release cycles. Rather than upgrading larger features to the latest approach, they opt to release a parallel feature that has the improvements. The reason for this is simple – upgrading introduces the likelihood or destabilizing the cooled core. The problem however, is that once this approach of parallel feature development starts, it gets hard to stop. It also gets pretty tough on the poor customer who’s constantly being left behind. Small incremental change is about customer success. It’s about taking your customers on a journey of on-going investment and improvement. One small step at a time.

The only constant is change – as they say 😉

Leave a Comment