Hello! I am super happy that this forum exists.
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?
Any thoughts or experiences with this is welcome.
Have you had any similar experiences @rjs?