20 days until #mtpcon London, the world’s best product conference
Book now
The Power Of The Perfect Slice "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs 15 March 2013 True Agile, Product Development, Product Planning, Mind the Product Mind the Product Ltd 772 Product Management 3.088
· 3 minute read

The Power Of The Perfect Slice

Perfect Slice Of Cake Agile methodologies extol the virtues of releasing early and using feedback to guide your product decisions. For new products, this philosophy works well and can avoid wasting effort building features that users don’t value. However, agile techniques often hit problems when used on established products due to stakeholder fears about brand and experience damage.

The conversation can go something like this:

Product manager: “I recommend we focus on the core functionality and release early to see how users respond. We can track usage, use dummy buttons to gauge demand for extra features and add a feedback widget to gather new ideas for improvement”.

Stakeholder: “But we have built this brand through painstaking work over the last x number of years. We cannot afford to undermine our credibility by releasing an unfinished product that doesn’t match up to what users expect from us. Plus, imagine the negative PR”.

Both sides make reasonable arguments. So what to do?

Sure you can try to insulate the brand from the nascent product by giving it a ‘labs’ or ‘beta’ label, but that’s hard if you are adding to an existing product and, for a mainstream brand, I wonder how much difference that really makes to user perceptions.

Having been in this situation a few times, I have come to the conclusion that it’s best to work in what I call ‘perfect slices. Now, ‘perfect’ is perhaps overstating the point. Nothing is ever perfect, but ‘excellent slices’ has less of a ring to it.

For me a ‘perfect slice’ is a fully formed feature where all the ‘layers’ –  from the database to the user interface – are properly executed, but where the scope is intentionally and sometimes drastically limited. It’s my belief that it’s often better to do a great job on a fraction of the functionality and completely leave the rest out, than it is to do an okay job on a longer feature list.

For example, lets say you are working on a product that helps people compare cars to buy. The core functionality is the ability to add cars to a compare list, view them side by side and highlight the differences.

The user stories might look something like this:
1. As a user I want to add a car to my compare list so that I can later view multiple cars side by side and make a better judgement
2. As a user I want to view my compare list so that I can see my potential cars side by side and make a better judgement
3. As a user I want the differences highlighted so that I can see at a glance where one car beats another and, therefore, make a better judgement.

So far so simple, but bloat can come into play pretty fast. Take the first point. Where can the user ‘add to compare’ from? Search results? Car detail pages? Other sites, via a browser bookmarklet? There are lots of possibilities.

Similarly, for point two, where can the user view his or her compare list? Does it sit in the user profile area? Can it be saved? Is it a tab in the search results? Is it public? Is it optimised for mobile and tablet? Can they view it in different styles like grid or list? You can see how simple stories can grow in complexity pretty fast if you let them.

My suggestion is to choose a single, core option for each story, often the simplest one to implement and focus on making the experience as slick you can. Ignore adding ‘compare’ buttons to search results if it’s complicated or creates dependencies. Ignore saving the ‘compare list’ to your profile if it creates an authentication headache. You can get to that if people want it. The important thing, remembering the conversation with your stakeholder, is that you produce an elegant feature that offers incremental value, upholds your brand values and offers actionable data to guide further decisions. This result could be described as a ‘minimal delightful product’ to use a phrase coined by Ian Lamont.

Far better this than creating a wider set of functionality with a mediocre or buggy user experience that clouds your proposition and could kill your idea internally before it has begun.

So next time you’re having that conversation with your stakeholder, don’t offer them something half baked, offer them a perfect slice now and leave them wanting more.

I would love to hear your thoughts and experiences on the topic of implementing agile techniques in established brand-driven businesses.

Alastair Lee is a freelance product manager and consultant. More at productpanda.com

Comments 8

What if the slice you choose doesn’t work? You could also release quick hacky products and drop the brand. The fact that you have the brand means you have lots of users you could expose the hacky product to. So long as it looked like they were going off somewhere else to use it, you get the benefit of being known and un-known.

Hey Jonny, if the the slice doesn’t work then you know your concept is flawed. However if you don’t execute properly you don’t know if it’s the concept, or the poor execution that’s the culprit, and you could cause damage to the brand in the process. Releasing hacky stuff under a separate brand or a labs brand is definitely another route for pure experimentation. But sooner or later you’ll have to integrate your innovation into the main product, and then you are back at the same question. 🙂

Good article. It is happens so fast that a feature goes from EASY to REALLY EXPENSIVE. From an outsider’s point of view that is not always obvious. So it is up to the product manger to communicate early & often.

I think your post is more a way to describe the idea of Agile with a sales tactic to speak with stakeholders who don’t understand that there is no such thing “perfect”.

I like the idea of perfect peace over half-baked cake.

Hi Erez, you’re right I guess I am reinforcing the Agile philosophy of biting off small chunks and doing each properly before moving on. But it’s worth mentioning because there can be pressure to prioritise functional improvements over getting the UX right, and that can be risky for brand-driven companies, IMHO.

A good example with the car comparison feature. I had that very dilemma on a car website project. We called it ‘my garage’…it got bumped down the backlog after many many meetings as we unearthed more complexity than first thought. The difference between a great product manager and an average one is to have the conviction (and evidence) to make clear, quick, and confident decisions. This is especially true on established brands/products where the product manager is the guardian of reputation and quality. The one tip I can share from my experience – stay objective – make decisions based on evidence. Every product priority decision has to be scorecarded – and ultimately one person needs to be accountable for that decision – the product owner

Join the community

Sign up for free to share your thoughts

#mtpcon LONDON | 20 OCT 2023

Join world-class product experts for a jam-packed day of inspiring talks and interactive sessions

Book now