The best product journeys start with a clear purpose. The practitioners and stakeholders should develop the vision together. It should speak of the "why" or the north star of the product. At this stage, one should avoid the "what" (solutions) and the "how" (strategy and goals). Instead, the focus is to envision an ideal state to which Practitioners and their stakeholders can agree and be aligned. The activities can involve a few rounds of deliberation, disagreements but it's part of the process. A good outcome for this approach is when the whole team and stakeholders land on a statement or two that is un-ambiguous and inspiring.  

Customers, though they contribute to the bottom line, are people. So even if the customer is a large organisation, you can boil it down to the handful of people who interface with or decide to buy your product. First, define customers into specific archetypes that fit a given behaviour, both positive and negative. These archetypes are alive; you refer to them when you speak of customers; e.g. what are the job stories for our Innocent Archetype? Next, refine the archetype definitions as long as your product or vision is alive via customer validation exercises such as Interviews, Observation and Immersion.

See a short video introduction​ of this approach.

What is the customer getting done with the help of your product? Using Archetypes for this is optional, but it would help significantly in narrowing the definition. For example, When my customer transacts using my application, they expect to see an acknowledgement from the app as assurance that the transaction was successful.. These job definitions are called Job Stories and can be very helpful in guiding the Practitioners as purpose statements for the product to be developed. For every product, one can write close to 100 Job stories with various permutations introduced through multiple types of customers and product features.
 

Create a product version resulting from minimum effort and cost to test if the customer would like it. It could also be called a minimum likeable product. The definition should be clear to the team developing the product. It must include the MVP's strategy, which provides well-known methods like Wizard of Oz and Concierge that talk about how to go-to-market with your MVP. The point of releasing an MVP to your customers is to learn how they used your product. What worked and didn't work? To achieve this, the MVP must have clear metrics that can tell you if it worked.

Ideas are exciting; it keeps teams inspired, but a concept that is not solving a customer challenge will not be viable (make you money) and usable (to your customers). Therefore, the more significant and more evident the problem is, the better it is for your idea. Spend time defining clear customer challenges and subsequently validating them with customers via interviews, observation. Then, as challenges are clear, proceed to a solution with the team through ideation sessions that involve everyone minus the judgment. Come to accept that ideas are nothing but an assumption of a solution until they are validated. It's not about landing on the "perfect" answer but rather ideas that come close to perfection as possible. You come closer to this perfection by prototyping and testing and repeating this until you are confident that this is what the customer will need.

For "business-as-usual" functions, the best way to begin the agile journey is to de-clutter existing processes. Remove activities that do not align to the desired end-state and reduce time spent on low-value activities through automation (e.g. RPA). A combination of identification, prioritisation and scoring reduces the overall complexity to achieve shorter Turn-around-Time (TAT), a quicker learning curve, and reduced dependency.