Product Development — A Tale of a Dragon Boy
As a father of two kids, I get to sit down, put my feet up on the couch and see a movie or two with them during the weekend. My son is 11 years old and, these days, he is into superhero movies, like Avengers and Justice League, and science fiction, like Star Wars. My little daughter is four years old and she still enjoys her downtime over an animated movie.
Keeping up with this tradition, a couple of weeks ago, I happened to see the movie How to Train your Dragon. I must admit that I have seen this countless times now; first with my son when he was around four or five years old, and now with my daughter. Being a movie fanatic myself, I don’t mind seeing a movie repeatedly; similar to little kids, I too have developed skills to enjoy a movie as if I’m seeing it for the first time: except this time — this time, I saw something for the first time!
A product was developed from scratch, for a very difficult customer, under extremely challenging circumstances, to address a critical requirement.
The plot of the movie (spoiler alert), is about a boy (whose name is Hiccup) who has been judged by his people as not being strong enough to fight dragons. Defying them, one night he ends up injuring one of the most ferocious kinds of dragon (whose name is Toothless) during a dragon attack on his village. Upon close contact, he realises these animals that his fellow villagers see as demons are not as bad as they think, and he starts getting to know them better. He tirelessly works on a way to make the injured dragon fly again, making it his closest ally in defeating another notorious dragon that’s being mobilising other dragons to kill and steal from nearby villages, including his. In the end, he manages to share his experience with the rest of the villagers and convinces them all, including his father, who is the village chief, to co-exist with the dragons.
My intention in this article is to highlight the process Hiccup went through in identifying the requirement, working with Toothless to successfully deliver a product that saved the life of his pet dragon, and the value he ultimately delivered to the entire village.
This re-stitched YouTube version of the movie demonstrates how the three main aspects of product development must come together to deliver a successful final product.
Let’s take a look at them in more detail.
Main Aspects of Product Development
1. The Requirement
… to find a way to make the dragon that has been injured fly again, so it doesn’t starve to death.
This is where the questions ‘What?’ and, more importantly, ‘Why?’ are raised. They define the problem all stakeholders want to solve: the ‘what?’, and the benefits it is going to bring by solving it: the ‘why?’ The requirement could be a gap in the market that no one else has filled or an added value for your customers to uplift their experience to the next level. Either way, the value that is to be delivered needs to be clearly identified and articulated, which is the destination of our product development journey. Without it, we may be setting ourselves on a path to failure.
2. The Customer
… a ruthless dragon that has not had any prior contact with a human. It is currently unable to fly due to injuries sustained during the attack and is desperate to regain its ability to fly.
This is where the question ‘Who?’ is raised. They are the individuals or group of people who will benefit from the problem being solved. They are the reason that the product is either going to exist or currently exists, and they will decide if the product is a success or a failure.
3. The Delivery Team
… a boy who passionately wants to help the injured dragon fly again and change his fellow villagers’ perception of dragons, which they have held for generations.
This is where the questions ‘How?’ and ‘When?’ are raised. The delivery team is the heart of the product development process; the team responsible for developing the product needs to be highly agile/nimble to respond to the continuously changing nature of the requirement and the customer. They need to be empowered to adopt a methodology, suitable to the problem and target market, to deliver a product as early as possible to validate the assumptions and hypothesises made, and to then adjust the shape of the product as quickly as possible. Without that, it will be irrelevant to the customer, outdated and not fit for purpose, ultimately being deemed a failure.
Now that you are familiar with the aspects of product development, let’s turn our focus onto the process that brings them together.
Now that you are familiar with the aspects of product development, let’s turn our focus on the process that brings them together.
Phases of Product Development
1. Identifying the Requirement
This is probably the most critical step in the development of any product. Identifying the customer requirement correctly will decide how complicated or simple the next steps are going to be. The challenge is to discern the actual problem hidden amongst the noise created by what the customer wants and desires. There are many techniques in the toolbox that can be utilised, depending on:
- Regulatory Compliance: the risks involved in the business proposition regarding health and safety concerns, government compliance, and regulatory requirements.
- Operating Environment: the amount of knowledge available on the customer and the market in which the product is going to operate.
- User Demographics: the number of predicted customers, their backgrounds, education levels, age brackets and social habits.
- Product Lifetime: the time duration that the product is expected to operate in its intended form or shape.
- Success Factors: what defines the successful delivery of the product, and the measurements stakeholders would like to track in order to identify customer engagement and areas of improvement.
Participating in key user group discussions, exploring commonly found knowledge amongst the public, conducting market surveys or research, and performing one-on-one interviews or group requirement gathering workshops are some of these techniques
Going back to the particular scenario presented in the movie, the Toothless is unable to verbally express itself to Hiccup, let alone articulate the requirement. As a result, he ends up utilising more intuitive methods of identifying the details of his customer’s requirements.
2. User Story Mapping and Product Backlog Prioritisation
This step goes hand in hand with the first step on most occasions. As we explore the details of the requirement, there has to be a way to capture them effectively and accurately. Story mapping is a great way to do this as it provides a visual representation of the details as requirements are captured. It will ensure the chances of missing crucial details that are pivotal to the success of delivering the right product are minimised or avoided altogether.
Furthermore, splitting the entire product development into manageable blocks allows the delivery team to deliver early, in smaller chunks, and more frequently.
Delivering Early: this allows both the delivery team and the customer to validate the requirement as soon as possible. Customers will have the opportunity to confirm if they have been successful in articulating what they need, and the delivery team can confirm if they have understood and captured the requirement correctly.
Smaller Chunks: splitting the entire product into smaller chunks contributes to quickly delivering a part of the product that is fully functional. This way, the delivery team can limit the time they will have spent on the product if the customer identifies that it is probably not going to address their problem. It’s the most effective way to validate the initial requirement and rectify any mistakes made.
Another benefit is the ability it provides for the team to respond to any changes to the requirement itself. For example, a feature that was identified as ‘needed’ may no longer be required in the form originally identified, or not required at all. By separating product features into smaller deliveries (also known as iterations), the team can either go back to the design board to alter a feature or drop it altogether.
More Frequently: delivering more frequently is another way to make sure that the delivery team does not end up spending a huge chunk of time and effort working on a product feature that might not provide the most suitable solution. An integral part of product development is to deploy it for production use. With frequent deployments, the delivery team can feel confident in associated tasks that are usually considered as both risky and critical, with the opportunity to execute them more regularly.
3. Story Slicing and Incremental Development
Each user story (usually corresponding to one capability in the product) can then be sliced into thin layers of incremental delivery to provide more transparency on the progress made and more flexibility on the work still to be done. Story slicing can be ‘horizontal’ or ‘vertical’.
Horizontal Slicing: this could also be identified as ‘feature slicing’ because it separates each delivery based on independent features of the story. Depending on what is involved, it may or may not include more than one delivery team across the organisation.
As shown in the video snippet, Hiccup concentrates on one feature at a time. First, he works on the tail wing, before moving onto the cord to control the wingspan and then onto the saddle.
Horizontal slicing is more suitable when the requirement is not fully understood and there is a need to bring a product to market quickly based on certain educated assumptions and hypotheses, in order to learn further from it.
Vertical Slicing: This involves focusing on developing components of similar types, before focus is shifted towards another type of component.
Hiccup could have focused on finishing up the leather fabric required for the tail wing and the saddle before moving onto finishing up the metal parts required for them.
Vertical slicing is more suitable for a ‘production line’ arrangement, where the delivery team has a high level of confidence in the features of the final product.
Consider a motor vehicle as an example where the feature set is fully understood, and all stakeholders are aware of what the final product is going to offer; in this case, you can focus on making the panels first before moving onto the interior parts, and probably increase productivity as a result.
4. Regular Product Demonstration (and Pivoting)
What better way is there to ensure that the right product is being developed than regularly showing it to the customer? The delivery team must strive to showcase the product as regularly as possible. This doesn’t necessarily have to take place until one of the capabilities (a user story) is completed. It pays to showcase bits and pieces of the product as they are being built, offering much-valued early exposure to the customer, to receive feedback of potential deviations from the original requirement.
Hiccup demonstrates this very clearly by trying his product on Toothless every step of the way. In fact, it was his product demonstration of the tail wing that gave him all the details for the next set of requirements, after finding that the dragon couldn’t control the wing attachment by itself and needed assistance.
Both the delivery team and the customer need to take part in product demonstrations with an open mind to identify critical requirement details that may have been previously missed or misinterpreted and to agree changes to the current development plan.
5. Delivery of Minimum Viable Product (MVP)
Minimum viable product is often a misunderstood concept. In simple terms, it’s a version of the product that will solve all the critical problems customers are facing. The word ‘viable’ is the hero of this abbreviation; it emphasises that the product needs to be viable in its mission to fulfil the critical requirements initially identified.
What MVP is not: a …
- minimal product: a product with a limited set of features, mostly due to time and budget constraints.
- simple product: a product with a set of features that is the easiest and simplest to develop.
- prototype: a product that is not functional and just pretending to perform the intended tasks required by the customer.
- proof of concept: a collection of different components loosely (and hurriedly) put together to confirm that the proposed solution to address the requirement is possible to deliver.
- trial/pilot product: a substandard product that is presented to the customer to collect his or her thoughts on the product.
Nonetheless, it is important to recognise that the above products types are important stepping-stones towards a successful MVP.
If you notice the way Hiccup went about developing the product for Toothless, he wanted to ensure that each feature included in the MVP addressed all the critical requirements so that the dragon could fly the way it used to before it became injured.
6. Continuous Product Improvement
Delivering the MVP is not the end of product development; in fact, it is the start of a successful product. An effective product development team will continue to work with the customer to identify the next set of capabilities to keep the product relevant, improve the experience it provides to its customers, and stay true to its original vision and mission.
New requirements emerge regularly due to…
- Increased levels of customer expectations: in addition to making customers happier, what happens with every good product is that it also makes them hungrier for something that packs even better features. A product that stops responding to this ever-growing thirst for improvement will get left behind and eventually become obsolete.
- Technological Advancements: at one time, Nokia was the most popular phone brand, which everyone dreamed of purchasing. When the technology advanced from hard-button to touch-screen phones, Apple embraced the change and became the brand to lead the revolution and to benefit the most out of it.
- Changes in the market: my viewpoint on this predominantly concerns changes in demographics. For example, a product must constantly evolve to cater to emerging customer age groups, educational backgrounds, and even cultural backgrounds to keep it applicable to the market in which it operates.
Looking back at the movie, Hiccup strives to continuously improve the product in response to difficulties Toothless faces in the initial product development phase. If you have had the chance to see the two sequels, you will notice how much he improves the entire product, including the surrounding eco-system, due to change in circumstances, new customer needs, and technological advancements.
Developing a successful product does not happen overnight or accidentally. It requires dedication to a cause, being committed to delivering what your customers actually need, and having an open mindset to act on areas of improvement by responding to change. What a movie like How to Train Your Dragon shows us all is that these ingredients are not something new to the Fourth Industrial Revolution we are currently in but have been around ever since the start of civilisation.
What we need now is to be mindful of them and to engage consciously to give the product every chance to be successful and improve the lives of our customers.
