Product development often starts with an idea and a blank sheet of paper. But how do you empower a development team to turn an idea into a product? A workshop can be useful for this, and I'll outline the process and content in this blog post. To get everyone started, I'll use a simple product example that everyone can imagine. It's a coffee mug for use in the car, which can keep the coffee warm thanks to an integrated heater. By now, everyone probably already has some initial images of a possible product in their minds, right? But of course, this doesn't yet clearly specify the product.
The Mission Statement
The mission statement is a short and concise definition of the development goal. It provides guidance throughout the development process and reveals to all involved what we intend to do. "We intend to fly a manned vehicle to the moon within this decade." This, for example, is a mission statement and clearly states what we plan to do. And what might such a mission statement for our coffee cup look like? Feel free to think about it yourself and write one down before reading on.
So, have you been able to come up with something? Feel free to share it in the comments section! I'm curious. Here's my suggestion:
No more cold coffee! Everyone who spends a lot of time in the car should be able to enjoy hot, delicious coffee while driving with our HotCarCup!
This may sound like marketing blah blah at first, but it actually contains a lot of information relevant to development. It mentions the target group, the product name, the usage scenario, and the location. It's best to hang this sentence where it's easily accessible to the team so it always serves as a compass and makes it clear what we're planning.
The system context
Once our mission is clear, we move on to the system context. The system context is a graphical representation of the system and the first diagram of the system architecture. It shows the system boundary and thus answers the question of what is part of the system and what is not. It shows the interfaces to other systems or people with whom the system interacts.
Such a diagram promotes shared understanding and clarifies many important questions. During the workshop, the diagram can be developed collaboratively, for example, on a whiteboard. It's important that everyone understands the diagram and can participate in the discussion. This shouldn't be a problem with the diagram shown above.
Ask the right questions to determine requirements
The goal is still to identify the requirements relevant to the product. This is achieved by raising questions and discussing them. For our example, possible questions could be formulated as follows:
- Which cars should be considered?
- What does the mechanical and electrical interface in cars look like?
- Are adapters required?
- What must a cup meet to be dishwasher safe?
- How high and wide can a cup be to fit into standard coffee machines?
- What are the ambient temperatures in the car?
- What should the cap be like so that no coffee is spilled but still remains drinkable?
- Are there any hygiene requirements for the cup?
- Are there normative requirements for coffee cups in cars?
You'll probably think of more questions. And many of them won't be answered immediately. But at least you're asking the right questions! These could be documented in a questionnaire, for example, and then answered one by one. This creates clarity for everyone involved!
The benefit of the product
A product is purchased because it has a benefit for the buyer. With a cup like this, the benefits can vary greatly. It could be a lifestyle product that the buyer simply feels good about using. Perhaps the product is particularly environmentally friendly and saves a lot of waste. In this case, the benefit of the product is not polluting the environment with unnecessary disposable cups. Or perhaps the main focus is on saving money, as the buyer can make their coffee at home more cheaply and then avoid having to buy it expensively at motorway service stations. The product's value proposition has a significant impact on its architecture and design. If the main focus is on price, then the cup probably has to be cheap too, and expensive materials cannot be used. This is probably different for lifestyle products. Therefore, clarify the product's benefit at the beginning of the project. Why would someone buy the product?
Conclusion
Workshops in the format described here are absolutely useful for enabling the development team to develop the right product. Because only if you specify the requirements correctly at the beginning can you end up with what you envisioned or developed together. But here's a warning: the world is changing, and with it the requirements for coffee cups. Here's an example: if USB ports become more common in cars in the future, the comparatively expensive plug for the cigarette lighter might be a bad choice (plus, the coffee cup with a USB port can also be used outside the car). Please bear in mind that, as a rule of thumb, around 2% of the requirements for a product change every month! It is therefore incredibly important to write down product specifications and keep an eye on them at all times. Requirements management tools (e.g. Polarion or Doors) are a MUST for complex systems! And as you can see, even an apparently simple system is more complex than you think and is by no means simple.
If you need help with product development, or if we should organize a workshop like this together, please feel free to contact me.
Best regards
Goran Madzar