3 steps to lean product development

Share on facebook
Share on twitter
Share on linkedin

The scenario

The ambition is huge. It’s a new subject area, a new piece of artificial intelligence, a new product integration: it’s going to solve everything. You have the budget, the time and the team. The excitement is intoxicating and the creativity is flowing.

Now, the voice of realism. Yes, everything is possible, and that excitement must never be lost. But it will always be a balance of the development team availability, breadth, depth of scope and time available.

A motivated and engaged dev team is the most consistent variable. The breadth of scope is determined by our various stakeholders (future posts will cover requirement collection and prioritisation techniques). As a product professional, the easiest to manage is depth. Too much depth, or quality of a feature, is an inefficient use of resources and will prevent you meeting the scope or cause late delivery. Too little depth, particularly if unexpected from stakeholders, will cause kick-back.

So, I came up with this approach to communicate depth quickly and easily, and get everyone engaged with being lean…

A few terms before we get started (for more, see Mike Cohn’s writings)

  • User story = something the user wants eg I want to download my air quality data into csv
  • EPIC = a big user story, eg I want to manage air quality data
  • Feature = a collection of user stories that work together, eg I want to see an interactive table of my air quality data (some people, Mike Cohn included, call these Themes)

Skimmed, Semi-skimmed or Full-fat?

EPICs are translated and broken down into Features. Every Feature is triaged into 3 categories:

  1. Skimmed.

The first pass of a feature consisting of the bare essentials, the smallest and easiest user stories to get it out of the door as soon as possible. It will be usable and functional but will not be polished. This is to ensure we get it to our stakeholders as soon as possible, and react to what the user really wants, rather than what we think they want.

2. Semi-skimmed.

The second pass: developing a feature so that it becomes likeable. What this actually means varies, it could be most intuitive UX, better UI, the ability to complete tasks on mass. The focus here is ensuring a positive emotional response.

3. Full-fat.

This should be seen as a bucket of unstructured stories. All the extra ideas and curveball suggestions; items that will make that feature distinctive but ultimately are too complicated or niche to deal with now. This enables you to capture everyone’s requirements, and ensure stakeholders feel listened to. Ultimately, if any of these items come to the fore, spin them out into their own discrete feature and deliver the skimmed EPIC.

The response

Yes, the milk analogy is cheesy. It does get a few bemused looks and comments. However:

  • It clearly communicates depth across multiple features
  • Stakeholders understand what they will receive, resulting in more positive engagement and less negative kick-back
  • It drives efficiency, the focus is on the Skimmed EPIC, i.e. get the job done

The best response? Across the whole of the team, across designers, developers and our co-founders, I consistently get asked the question:

“Is it skimmed though?”

Share this post

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn

Become a sustainability pioneer!

Sign up for updates on all our latest posts and content delivered straight to your inbox!

James Farrell

James Farrell

James is the Product Owner at Qualis Flow. With an academic background in physical geography and vast experience in environmentally focused organisations as well as SaaS businesses, James is motivated by creating innovative products that drive a sustainable world.

Sustainable construction is within reach

Want to learn more about Qflow?