“Let’s create a great customer journey!”, we all heard about this before in various design / project meetings.
My point is, we cannot create a journey for our customers, but can only facilitate the customers to create a great journey by themselves … and each of these journeys is different.
One trap we keep falling into, is we think customers start their journeys from one end, and then end in another end, flawlessly.
In reality, each customer has his / her own journey with us from any touchpoint we are offering, to another touchpoint with or without a successful journey / transaction / interaction. The customer will just bounce back and forth among various touchpoints we developed for them. Therefore, the team shall design a whole customer journey WEB or MAP, instead of just a simple one-direction customer journey.
Many companies embark on their innovation journey by creating an Innovation department, hire a new chief / geek to lead the team, renovate the office to make it cozy and colourful, employ a new design methodology etc. etc.
What we really shall do first however is to abandon things … aged old mindset, archaic thinking, obsoleted KPIs, and organizational red tape.
“Fail fast and learn fast” may be true, but it’s a bit too cliche, isn’t it ?
Every product team says they shall ship quickly with a MVP, and it shall be a team culture where people have the freedom to fail, such that with each failure the team can learn something that enables success.
However, to encourage product team to try and learn, the key is not about failing fast but to fail (if you have to) with a minimal cost. So how can we lower the cost of failure ?
The answer is a combination of cloud based infrastructure, API / microservices technology, data sandbox, UI / UX prototyping tool, agile development, group of targeted beta testers, robust security framework and relevant KPIs.
Even though one of the most popular answers in recent months to the question “Who led the digital transformation of your company ?” is “COVID-19”, the fact is it only moves the needle a little bit for most companies. Reasons being that they are still struggling with traditional KPIs, poor data, legacy processes, hiring freezes, budget cut, multi-level governance models etc. etc.
However, the hardest part is still the fact that most teams think or decide beforehand that transformation can’t be done.
No, with right people and right mindset, it can be done.
MVP – Minimum Viable Product, a buzzword used by many product teams and startups around the world. Some deliver their MVPs like the donut on the left, some deliver the right one. Some roll out free products, some insist the customers have to pay for the new product. Some are happy to release a MVP that comes with 5 features, and yet criticise another competing product has _only_ 10 features etc. etc.
My view is we all have different interpretations of the keyword – “Viable”. Therefore, some of you think your customers can live with a V1.0 free product with only 5 features, some have to make it sellable with a good price and feature set – Minimum Sellable Product (MSP). Yet, some teams just want to develop something people love to use – Minimum Lovable Product (MLP).
So … before defining the scope of your MVP, first thing first … define your version of the keyword – VIABLE.