The teams are busy. The managers are managing, the makers are making. Everyone is pushing hard, going the extra mile, giving their all. Panic. The (invented a.k.a. budgeted) numbers are not being achieved by the big release everyone worked so hard for.
Fear starts spreading. I can hear the executives calling: “We need solutions!”, so people come with solutions. Well intended, creative and detailed solutions. Then ship ship ship, work harder, faster, more.
Crickets. (…then unfortunately the process begins yet again)
It’s not uncommon that this is exactly how many people would describe the process of building products.
It couldn’t be further from the truth. For good teams that is.
For a repeatable process, luck is not a good ally. Neither is pushing your people over their limits every day.
Without scrutiny, without a thorough understanding of the problem, without feedback from users, without direction any solution will do. That’s exactly why many solutions fail. They are simply not fit for the purpose. They are not solving the problem, because they started as solution. Solutions are a means to an end. Solutions are tailor-made to problems in the real world. Problems users – people – have.
Okay, so once we understand the problem, what does a solution look like?
Solving problems, like eating a steak, is best done piece by piece. Solutions should be bite-sized too. It is hard to swallow everything at once.
SECS – The smallest effective change shippable
Breaking down problems into smaller problems and parts that can be grasped and tackled in a short amount of time is an essential skill for any product person.
Impacting metrics and bringing business outcomes to success requires an efficient use of time. To use time efficiently, what you work on must be useful to reaching the goal. In other words, you need to work on things that are effective as measured by the desired outcome.
Product teams hence do well when they are actively seeking the smallest effective change shippable (SECS). Let’s dissect this acronym.
Smallest
I feel this doesn’t need too much explanation, but there are no hard and fast rules. The rule of thumb I can give is: As small as possible, as large as necessary to be effective.
Now this is more art than science to be spot on with the size of the change, so here is some guidance on detecting if it’s too small or too big:
- Too small: What you shipped didn’t do a thing. You will need to iterate on it. Warning, this could also be caused by not understanding the problem well enough and creating the perfect SECS for a problem that does not exist.
- Too big: What you shipped didn’t do a thing. Yes, this is exactly the same as above, except that you burned a lot of money. It is better to err on the side of too little, than too much, because not doing something is free vs. doing too much is very costly.
- tl;dr: Smaller is better (and faster, cheaper, easier, safer, fixable).
Effective
Now let’s turn to how effective the change is (you are chasing business outcomes after all). For this I like to turn to these four questions:
- Is it providing value to the user? (valuable)
- Is it viable for the business? (viability – does it support your business outcome?)
- Can we pull it off well? (feasibility)
- Do the users understand how to use it? (usability)
Unsurprisingly these are the exact things you should be investigating when discovering the problem space and coming up with a solution. So if you did your job well as a product team and understood the problem, tested the solutions, and picked the one that works to be shipped, there should be little surprises here. Well, if you didn’t do your homework, it will be pure luck if it works out.
Change
Let’s talk about change. I mean changes in products, not organisations.
Change is often interpreted too narrowly (as software feature shipped). Keep in mind that the product experience is the human interacting with your software, it’s not the software only.
What you ship must change something for the user. It can be a feature in software or a different process or a help-page or removing friction of some sort. Change the experience for the user.
Shippable
The reality of your product is the one users see. You need to bring changes to life, to affect the user, as mentioned above.
The change needs to be something you can actually “ship”. Hence, “shippable” really means that your product team can do the change. If you know the solution, even build the solution, but can’t bring it to the user, it is not shippable. Even worse, it’s actually waste. Make sure you can and do ship solutions you create.
tl;dr
Solving problems, no matter their size, requires many small solutions. Identifying the smallest change that will do the trick, is the trick. Everything beyond that is waste. Start with “not enough” and creep up to “effective”. No big bangs.