Definition of “Designed”

A short post on knowing when our product development can move to Sprint.

When a squad member finishes an item in Sprint, they go through a list the team has written called the definition of done. It’s how they know the work should be absolutely ready for release.

In the Product Development squad at Keypath I was trying to work out where our own bar is for “done” or, “designed”. Often I use the Kano model to help guide the team and aim to trim our MVP (Minimum Viable Product) down to hit basic. That way the users can reap the benefit of the outcomes sooner and we can move on to the next feature set or product.

This afternoon though I had a moment to pause for thought. If Keypath’s motto is, “be bold and do meaningful work” should we really be aiming at basic still? Wouldn’t bold indicate that we should be shooting for satisfiers and possibly delighters before moving on?

Where does bold sit on the Kano model?

For example, we’re developing a piece for a scalable learning tool and the outcome would greatly reduce code tinkering and offer a hosted solution for the tool. With the MVP at basic, we would produce a piece that has fewer risks but it still might cost the LD (Learning Designer) some time to release. Is that really bold? Is that really enough?

Being bold would mean creating an MVP and releasing it to some users, but keeping going until we’ve hit the satisfiers level, i.e., in the example, the outcome is no code tinkering and it being hosted solution.

Is our definition of “designed”, when we’ve finished basics and the satisfiers now?