Product Sashimi

*I wrote this post for the [Communitech blog](http://www.communitech.ca/category/blogs/). It’s cross-posted [here](http://www.communitech.ca/how-product-sashimi-gives-startups-some-wasabi/).*

Say you’re about to start designing a software product. You’ve got a few ideas and a blank whiteboard. You’ve gathered together people who understand the problem you’re trying to solve and the people who will value the solution.

You *could* brainstorm a bunch of features and start building them, but how do you know which features will actually be used and which will end up buried in some menu, untouched?

To avoid that, you need to get your product into the hands of users in order to get feedback (and revenue) as soon as possible. “Product Sashimi” is the term coined by [JB Rainsberger](http://jbrains.ca) for a set of techniques that help you thinly slice your product to deliver the simplest thing that could possibly work. Delivering a simple product early means you can find out directly from your users what additional features they would find valuable so you don’t have to build the ones they won’t.

JB discussed Product Sashimi with [Waterloo Agile Lean](http://waterlooagilelean.wordpress.com/), [Communitech](http://www.communitech.ca/)’s agile software development P2P group at our [Feb 22 meeting](http://waterlooagilelean.wordpress.com/2011/02/14/agile-lean-p2p-feb-22-product-sashimi-simple-techniques-to-slice-products-thinly/).

If you have a nebulous product idea, the first step is to break it down into 8-12 broad feature areas (having more than 12 feature areas means you probably need to break down your idea into multiple products) that can be delivered independently. To do that, the first technique of Product Sashimi is what JB calls **The Chet Hendrickson Technique**. Once you’ve identified the inputs and outputs for a system, take the role of a piece of work in the system. Tell the experts, “I’m an [input]; I wanna be an [output]. Try and stop me!”

Say you’re building a loan processing system. “I’m a loan application; I wanna be a cheque. Try and stop me!” might prompt questions like “How I do know you’re who you say you are?” or “How’s your credit rating?” Then you know your system needs identity verification and credit check features.

Once you have a list of product feature areas, you need to break that down further into a series of concrete examples you can test. The goal is to generate the set of examples that gives you a minimal viable product. To get there, JB describes the second Product Sashimi technique: **Contract and Expand**

1. Write *any* concrete example.
2. **Contract**: Look for ways to make the example *simpler*.
3. **Expand**: Generalise the simplest example in *one direction* at a time.

JB has a [blog post on Contract and Expand](http://www.jbrains.ca/permalink/three-steps-to-a-useful-minimal-feature) where he give a detailed example of how this works.

What example you choose is less important than it being a complete example with concrete values, representing a user’s choices through the system. This will form the basis of an executable test of the system. If you leave out those concrete details, others will have to make assumptions which might prove to be wrong.

In the Contract phase, you’re peeling back everything that’s unnecessary in the system, leaving only what’s absolutely necessary to accomplish the task the user needs to perform. This will likely involve making the result not at all user-friendly. The user may need to remember and correctly enter their own account numbers, for example. But by implementing just this “walking skeleton,” you have a working prototype you can test and discuss with users.

The Expand phase is when you can add back the rules and usability requirements that you removed during the Contract phase, but you do it in a controlled and modular way. These features can be prioritised and implemented independently. They shouldn’t be tightly coupled, as they likely would have been if they were implemented as laid out in the original example. More importantly, you can avoid wasting time implementing features and niceties nobody cares about.

I’m not doing JB’s ideas enough of a service briefly summarising them here. The talk he gave to the Agile P2P was itself a summary of a [training course](http://www.jbrains.ca/training/product-sashimi) he provides. There’s no debate in the Agile/Lean community that releasing early and getting feedback as soon as possible are critical to creating a successful product. These techniques help you deliver the product your customers actually want.