Why successful products do pre-studies — A case study of BøthOfUs

There might be better ways to get things done than sending a list of things that need improving.

*The BothOfUs product development process

Recently we returned from running a pre-study workshop with a team in Germany. Whilst there, we discussed a great number of topics, from company long term and values to one of my main goals, the biggest problems facing the team at this time.

We love facilitating workshops, it offers a great opportunity to really explore a topic and get a real understanding, which is often hard to achieve in the business of our usual daily tasks. It also offers an opportunity to add real value to the product and help the team save €10,000 — €50,000.

This time we were running an 8hr workshop spread across 2 days. It doesn’t sound like much however, by the end, I think all our minds were feeling thoroughly used. Our goals, how to automate the current process quickly and how to handle this in a way that won’t cause issues for less tech-savvy existing users.

Sounds quite straight-forward. However, as we found out, that really depends how impressively organised an individual can be. We were blown away by how complex the existing, more manual structure was. We have a lot of compassion for the team keeping that together to succeed.

*we suggest different workshop models dependent on the team goals

When we start a workshop, we always start by trying to get the full download of where the product is at, it could be just an early idea with a couple of lines and we need to discover together what the problems are to solve for these users or a mature, released project on its’ nth iteration looking to add a new feature.

In the Google Design sprint, this is Day 1. A full 8hrs into just understanding the problem, that is how important this is to the Google Ventures team, this step will drive everything that will come out of the workshop so we treat it with great reverence.

Many workshops we run might only be 4–8hr workshops, so we have the fun of getting 8hrs of results in only a couple of hours. Here we try to understand who are the main users, what is the problem to solve, why this problem, how valid is this as an issue, what might be the causes and effects of this issue. These issues are best expressed from different perspectives so it is always valuable to have a range of experiences and expertise here. Once this is achieved we can move to my favourite part, solutions!

The second part of our workshop focussed on Day 2 of the google design sprint, where we considered solutions for the problems we have outlined. A common phrase we hear about this stage is “if you can’t find 20 different solutions, you haven’t understood the problem properly”. We don’t need to come up with 20 solutions each, however with several experts we should create sufficiently diverse ideas here which we can discuss and take with us to prototype and test. I think everyone always enjoys the solution stage because after sitting and talking about problems it feels productive.

By investing time to get on the same page and inform each other of the different problems faced by different departments, we can collectively innovate to solve problems using expertise that each department may not even be aware of. Having understood several key places that could potentially be automated we explored how the flow might be affected by automation, what solutions needed implementing most urgently and how to plan for implementation. It is usually here we bring in the project management triangle or bring in the principle of MoSCoW. We do this to remind ourselves we are still human. Some solutions are simpler and add a lot of value, whereas others may add less value relative to the cost to implement. The key focus throughout the workshop is adding VALUE.

By this time, we have a good understanding of the intended solution and how we would aim to implement it so we can proceed to prepare the Software Requirement Specification (SRS) or scope document. If we have extra time it can be valuable to begin prototyping at this stage however it is not imperative as we can also begin this during the next steps.

The SRS acts as the guidelines for what will be done by the team implementing the solution. It clearly outlines flows, what features need to be included in the solution and how it should be done. We aim to send this within a week of completing the workshop for feedback and this time we had a few tweaks to include, this gives us time to rethink any decisions we made that we are not clear on and to make sure all the information was accurately understood.

Once the SRS is confirmed we discuss the requirements with my own team to prepare estimates for implementing the solutions, this gives the team guidelines on what to expect from any team attempting to implement the solution, if the estimates are wildly different it could be the requirements have not been understood or the quality could be lacking.

*what deliverables to expect for an SRS or prototype

On some occasions we may be asked to prepare simple wireframe prototypes along with the SRS, we would usually advise this since having an agreed visual outline can save a lot of time and cost however it is not always needed. In this recent workshop, wireframes were not needed.

This full flow has been shown to save teams between €10,000 — €50,000 by helping to prioritise adding value and by aligning the teams to implement the solution in a more linear fashion.

If we were to re-run this workshop, we would probably remind ourselves of a few things. Firstly, manage the time carefully. I think we pushed everyone too hard on day one which might have been less efficient and left us less time on day 2. Furthermore, we would like to prioritise the scope to be automated earlier so we could spend more time deciding what could be implemented at a later date, particularly since this iteration had a tighter deadline than other projects.

You can read more about our workshops here — short.bothofus.se/s/vHAXz

If this sounds interesting to you, let us know! We’d love to have a chat! Book a 30 min free call — https://calendly.com/kay_bothofus/intro

Kay Nag — Co-Founder

https://www.linkedin.com/in/kaynag/

Marina — Spanish speaking countries

https://www.linkedin.com/in/marinardz/

Joel Yeap — UK & English speaking countries

https://www.linkedin.com/in/joel-yeap-6138b8192/

*********Thank you*********