One of the classic tricks of Product Management and design thinking is the “crawl-walk-run” approach of breaking down a larger project in to smaller, digestible and easier-to-tackle work packages. Like a small human child, a new product isn’t born immediately running, but will take time to crawl on all fours. After, the child will learn how stand upright, take its first steps, walk, before it eventually runs – preferably away from parents, around a table, after the cat.
Breaking down the fully developed vision and picture of the product of the future into smaller chunks that, step by step bring you closer to that vision-turned-reality. That’ll make it easier to focus and break down the smaller steps, and build out the smaller chunks, get them done, fine-tune them, move on to the next.
The challenge in all of that breaking down into smaller chunks is that you want to deliver a working product every step on the way, such that it works, delivers value to customers and users and allows you to progress. At best, customers and users are committed enough to give you feedback that informs your fine-tuning and next steps.
Let’s design a thermostat that’s hanging on the wall of a hotel room, and let’s try to apply the crawl-walk-run to build it quickly, and then innovate incrementally. We’ll need to start with a crawling minimum viable product, and go from there. The thermostat should allow guests to adjust the temperature in their room, by regulating the room temperature through warm or cold air. Guests should be able to use it on their own, without needed the hotel staff. Since we want to expect international guests, localization must be accounted for – graphics and pictograms where possible. That’s already a good set of requirements. IF this is the first time we’re building a thermostat and room climate system, we’re not too sure about very specific requirements like airflow KPIs or KPIs about bringing a room from “very hot” to “very chill”. We could deduct a few things from the general knowledge of what the boundaries of “feel-good temperatures” for humans are – but these are too wide and fairly individual, so we may not be able to deduct a good set of requirements.
Let’s start off slowly:
Crawl: we need to get an MVP going that already provides value, so that hotel guests will want to use it and that is working. At the same time, we don’t want to overdo with non-essentials, but focus on the most important stuff. The UI will start very basic – we’ll have a dial that understands three states: “Off”, “Cool”, and “Heat”, represented by an “On/Off” pictogram, a snowflake and a thermometer symbol. Guests need to select either state for as long as they need the respective function and then manually stop, when it’s enough. They see it’s working by an LED indicator. Air would flow in the desired state would start, first from a baseline temperature and then slowly converging to a maximum temperature in the desired state. So if a guest would choose “Cool”, they’d feel the airflow starting from the “base” temperature getting colder progressively, until it reaches the “maximum cold” temperature, and then keeps flowing on that temperature.
We’ve built the foundation that proves it can be done, built the minimal user experience, but we have a few flaws: no one will use the thermostat to run over night or for several hours in either state – in fear of either freezing or melting over night. We’ll need a few additional controls to improve on user-driven configuration and satisfaction:
Walk: Let’s add more UX components. The two-state system will be enhanced by a timer function. It’ll work simple but effective: through the push of either “+30m” or “-30m”, the currently selected state will be kept for the duration of the selected time, and then stop. The buttons set the timers to 30 minutes forward or backwards. This should prevent the system from endlessly running, and allowing the guest to start the system and go to sleep. We’ll add a small display that shows the number of minutes remaining that the system is supposed to run in that mode. We’ll also improve how airflow finds the target temperature, so that it goes faster to the “maximum cold” or “maximum heat” setting. Depending how complex it is, we may also build in another button, that allows a “fast mode”, which opens a second outlet for air in the room. Clearly that requires that the room layout and piping (the backend) supports that.
We now have a working system that guests will enjoy. It provides more flexibility and better user experience. How about we build on top of that, with a few things in mind: premium user experience, more control that also helps keep the cost down, by enforcing safety boundaries.
Run: Next, we’re placing one or two (for larger rooms) additional temperature sensors into the room. Also, we’ll change the user experience to give the guest options to define their target temperature. The temperate can be set within safe boundaries that most guests will find comfortable: between 18°C and 25°C. Guests choose the target temperature by reading off the display, and increasing the target temperature by using +temp or -temp via buttons. We’ll find out that we reached the temperature through the additional sensors – and keep the temperature within a margin. Setting safe boundaries will keep our cost down with extreme temperatures in the room – no one has to keep tropical plants during their stay – or host penguins. There could even be a regular check with outside sensors to feel the outside temperature, to prevent the room from cooling down too fast, if it’s freezing outside, or having someone from turning the heating up too high, if it’s already hot outside.
…and beyond: there could also be a smartphone app, that connects to the thermostat via Bluetooth or WiFi, to control the temperate from bed or bathroom. It could guide the guest and even suggest temperature adjustments, based on the outside temperature. It could suggest that, during night, the sleeping temperature could be adjusted to slightly lower, and automatically increased for when it’s time to wake up. The wireless connection with the smartphone could sense if the guest is still in the room or even in the hotel, and default to a more eco mode, until it senses the guest coming back into the hotel, through the lobby or the garage by connecting to Wifi – or the guest telling the app that they will return in 10 minutes. That could give the system the signal to bring the temperature, slowly, back to the desired setting.
For now, this all looks well balanced, allows for slicing and dicing it down into sprints or quarters or other sizable packages to design and deliver, and focus on. It also offers additional value from iteration to iteration, so that there’s extra user delight, actual improvements for user and system – that help inform decisions for the funding.
In terms of funding, some of the features could be turned into “Premium” experiences that either only exist in more luxurious rooms or are given to guests through a hotel points or program. That could be the smart phone use case – if the guest is likely to stay often in the hotel (chain), they’re likely to download the app – and re-use their comfort settings from room to room they stay in.
That’s how, in a nutshell, the crawl – walk- run approach could work to help bring down a sizable project to more digestible pieces. In each of the stages, you could collect customer or guest feedback and incorporate their ideas – and prioritization – potentially pulling forward some of the things you may have thought may come in “run” only, but are required in “walk” already – and vice versa – move unessential stuff out from “walk” to “run” – or beyond.
FRICKELSOFT 