Digital technologies aren’t simply opening up new markets; they’re changing the way we create and deliver products. Business models, especially consulting business models, that are effective today may be obsolete tomorrow.
Our clients are changing their expectations of how we can unearth and solve their problems together. To attack early stage, high risk, multi-factor problems most efficiently, we’re testing out a method, which we call MVP. We've run a number of rounds, slightly tweaking the method each time. We've now settled on an approach we think helps us get to the core of an issue and prototype and test solutions very quickly.
MVP does not always stand for Most Valuable Player. In this case, it refers to 'Minimum Viable Product'. We define MVPs as products with just enough function for a user to understand it, and give feedback. This could be a working phone app, or simply a set of hand sketches. This bare-bones product helps us figure out if people want it (desirable), if we can build it (feasible) and if someone would pay for it (viable).
If all three of these criteria are met, the MVP can be refined and brought to a wider market. If not, any feedback can be implemented into a redesign or dropped completely. This high intensity feedback loop saves us and our clients time, energy and money.
We have run a number of MVP projects. Each time we pair traditional engineering disciplines with digital and design practice leaders. We bring in design and digital tech experts as we need to, borrowing from lean methodology and design thinking common in the tech industry or applied academic groups.
In MVP Round One, we explored how we can use technology to increase the social connectedness of our cities —The Internet of Things and Social Cities.
For MVP Round Two, we looked at how we can automate some of our more repetitive tasks. This led to the conception of HERMES, a robot we are now perfecting to automate parts of our 3D scanning business.
In MVP Round Three, we tackled the problem of how to help citizens see how future building plans might impact their streets and neighbourhoods, so that they can give informed feedback. We worked with buildings engineers and software developers to see if we could develop a full product—from idea to physical prototype—in 40 hours. Below the team tests the tech with people out in the park next to our office. Don't worry, it's not meant to have sound.
The first time we showed up to test our prototype, our team was coincidentally all wearing white shirts and dark jumpers--the standard uniform of the engineer. “You look like you’re trying to sell a religion” a nearby construction worker said as we approached, smiling politely while holding our clipboards.
Outfits aside, we found some takers. We asked citizens, councils, developers and design groups if they’d use our product. This formal and informal feedback gave us an early indication of the product's potential straight away. This followed on from testing technical feasibility by challenging ourselves to build a basic mixed reality app using Hololens and Tango in a few days, and testing viability by considering the business model from day one.
"We are essentially trying to find a prototype within a prototype. The small prototype is the product being built. The big prototype is the process being tested."
Building, testing, breaking and re-building is the fundamental principle behind MVP. It helps us learn as quickly as possible. Rapidly and repeatedly testing our solutions with colleagues, clients and the citizens means we are able to fail some ideas faster than we otherwise would have while accelerating promising projects to market quickly.
The first hurdle is always to define the problem. Sometimes, as technical people, it’s easy to get carried away advocating for potential solutions. Apps! Dashboards!! Automated Parametric Design Software!!!
We find it’s more valuable to first spend time getting close to our clients, client’s clients and end users. Turns out, they have the best understanding of what their problem is.
“How do we design for a user experience when we have lots of different people who have lots of different needs?”
While the problem is still being understood, it’s okay to meet each other halfway and half dressed. Within the clear structure of MVP, our partners are enthusiastic to develop ideas with us. We share where we see value and - perhaps even more importantly - where we don’t. It turns out the excitement of trying something new together is contagious.
Our original idea for this project was to use Hololens. This tech allows the user to see a model - in this case, a building - imposed on the street using a partial headset in an immersive virtual reality experience. This seemed like a great option. One rapid prototype later we realised our mistake—Hololens does not work too well outside. The prototype wasn't feasible.
We switched to Tango for the next iteration. Tango operates via an enhanced smart phone or table. A camera and sensor array simulate a mixed-reality, superimposing a model onto the streetscape when looking through the device. Bingo! We had ourselves a workable prototype.
"Technology is the answer, but what was the question?" - Cedric Price. Let the problem inform the solution and not the other way around.
To test our assumptions about the viability and desirability of the project, we showed people on the street three version of the same building—a planning notice, a picture of the proposed building and the Tango mixed reality app. Every one of our users said they understood the impact the building would have on the streetscape more when using the Tango.
Our lesson? Technology should only be used as a tool to solve a problem when it’s suitable. Even then, the least tech version of a solution is often the most elegant and effective.
In fact, before we had developed the full prototype we showed a hand drawn plan to clients. It worked just fine to explain what we were proposing and generate enthusiasm for the idea.
We took the lessons learned from Round Three and tried a different approach in Round Four. This time, we worked with our acoustics team to try to create a simpler planning process by following a five day Sprint methodology. Below the team shares their experience.
We'll be kicking off Round Five this year. If you'd like to work with us on these programs, please do contact us.
This story was written by Jeff McAllister, as part of the Research Review. This series is produced by the Arup Australasia Research team; Alex Sinickas, Bree Trevena and Jeff McAllister with contributions from Sheda and Noel Smyth.
Ask Alex about
We work with industry partners, governments, universities, startups and community organisations. We do this through research partnerships, and as consultants and facilitators for foresight, research, storytelling and technical writing workshops.