We are considering adopting Shape Up across our teams but I have a few questions that I hope you guys can help with.
Before we release to production we use a number of techniques to understand the user problem and narrow down potential solutions. Such as user interviews with rough and ready prototypes, releasing daily to users in a beta environment etc. We learn a lot from this and feel it is a quick and “cheap” way to learn without building for our users in production.
If we were to adopt Shape Up we would still want to benefit from these ways of learning and I would imagine that it would become part of the shaping process. This is where the problem lies. Naturally these techniques result in higher fidelity artefacts than Fat Marker sketches. i.e We learnt from 2 days of testing that users really did not understand the purpose of a button until we added a label for clarity, therefore we would want to include this type of detail in the brief. OR we tested this specific flow with 100 beta users and we achieved the expected outcome.
This does however go against defining a project a the right level of abstraction in the Shape Up world. Has anyone succeeded in specifying this type of detail into a pitch or would we need to drop these techniques to make Shape Up work for us?
Perhaps we can include “important detail” such as the examples above in the pitch but specify that the remainder of the scope is flexible or something else?
While I’m not sure if you would need to drop those techniques to make Shape Up work, it definitely would be the easiest option - and the one we have chosen to do so far. Remember that one of the key parts of Shape Up is in making trade-offs. The time is takes to do all that research and the impact that has on your ability to deliver things within your appetite or extending the length of your shaping stage is something you need to decide for yourself if it’s worth it.
When you’ve already spent the time and resources building something to release to a beta environment, the difference between that and building for users in production is a semantic of which environment you deployed to. From a betting perspective, you’re chips are already down on the table
For testing UI/UX things like the clarity of a button label, we’ve found we can do that fairly quickly by showing it to people internally (or my mother for the ultimate test! Haha). 2hrs walking around the office showing people a mock-up or even a fat marker sketch with the button label is much quicker than taking 2 days for user testing. In most cases, understanding a UI/UX is a human thing, so anyone can help with that, it doesn’t have to be users. And if you’re testing whether your solution solves the problem, then I would suggest that means you didn’t spend enough time validating your understanding of the problem up from prior to shaping.
So as I said at the top, it’s all about making trade-offs and what you think is worth your time the most. Another thing you could try, if you do want to test with high fidelity prototypes is that once you’ve done the testing and are happy with the various labels and flow etc, throw out the prototype. Include the “important details” in the pitch, as you suggested, but don’t give the team the high fidelity prototype. Still only give them an abstract sketch and concept, so they still have the freedom they should within the Cycle, instead of feeling like all the details have been decided already - which a high fidelity prototype would usually do.
Thank you for taking the time to reply. This all makes perfect sense to me and will help me to make the right decision.
If you do want to test with high fidelity prototypes is that once you’ve done the testing and are happy with the various labels and flow etc, throw out the prototype. Include the “important details” in the pitch, as you suggested, but don’t give the team the high fidelity prototype.
I was wondering about this idea but I think that it will be a difficult sell to our Product Managers. It still feels like not taking advantage of our previous learnings. I do think the easiest option is as you suggested to drop steps such as releasing to Beta for features that are going to be handled in a Shape Up way.
Hey @Aylon thanks for this, it has some great points:
The chips are already on the table if you’re “learning as you release”
Testing UI/UX can be done internally because usability is across humans (unless we’re talking accessibility issues), and you’re not going to get value validation no matter who you test with at that point (too late)
Throw away the prototype if it was used to figure stuff out during shaping, and give the team more abstract assets in the pitch.
Appreciated your presentation at the Auckland ProductTank meetup the other day
