Digital Transformation Awesome Product Owner

One of the expected outputs of digital transformation should be epic digital products. Products that engage, add value and seamlessly intertwine into the lives of users. Nostalgic reference alert… Digital transformation is tough and requires the A Team which should include a “Hannibal Smith” Product Owner (PO).

So what is a PO? I remember attending an Agile conference last year and the speaker summarised the PO to be “the CEO of the product”. The definition sounds very succinct and seems relatively simple. This is not the case, the role is hard to define as each organisation differs in construct, industry and maturity. This is my take on defining a PO: my personal, ‘practical hacks’, signposted #POHack.

What makes a PO Awesome?

In his book Essential Scrum, Kenneth Rubin defines a PO as:

“Empowered central point of product leadership…they must understand the needs and priorities of the organization, stakeholder, customers and user to act as their voice and ensure the right solution is developed.

There a few key things to expand here.

– Empowered: A PO that is not empowered is like a car with an underpowered engine. Everything will work fine on level or down hill roads, however when things get tough and there is a steep hill to climb, work comes to a halt. I am not saying the PO should make all the decisions in silo, but if your PO is always checking in with a ‘supreme leader’ for every decision, then your PO is not empowered. It is important for the PO to find the balance of making decisions and knowing when to ask other for advice and guidance, this can be very tricky to calibrate and usually achieved through trial and error. An empowered PO makes decisions and has the trust and backing from any ‘supreme leaders’ – this ensures they are the right, powered engine, to drive the product forward.

– To ensure central point of leadership and understanding priorities, the PO should collaborate with the development team and key stakeholders, ensuring everyone has a good understanding and vision of the product.  As well as being servant leaders, a PO should build trust, focus on the teams needs and most importantly for me, make working in the team fun. The PO will arrange the team based on skills and people’s aspirations and ways of working, to ensure a cohesive team working towards common objectives.

– Act as their voice and ensure the right solution is developed: understanding what customers want is not easy. It requires a customer-centric growth mind set; feedback from customers and data orientation to prioritise accordingly. The PO should avoid ‘KIA’ (know it all) syndrome. I have seen many POs focus on non-representative feedback, or not seek customer feedback and go with their gut feel instead. This is dangerous and most probably leads to the product becoming irrelevant to the customer base. There are many feedback options such as tagging, analysing data, conducting surveys, prototype research and A/B testing. To ensure longevity and aid navigation of a product, it is essential to create an enduring feedback mechanism into the product lifecycle.

#POHack:  Instead of guessing how the customer will use a new feature, I test different options through paper / clickable prototypes with colleagues or the general public, offering them free coffee for their time. Observing, using eye tracking, capturing empirical data and asking open questions always reveals golden insights. It is crucial to evaluate assumptions as early as possible with real users – the feedback given will help shape the end product.

What domain knowledge should the PO have?

The three main domains that a PO needs to work within in are: technology, business and user experience. A good PO will be an expert in one of these domains, and be passionate about the other two. However, an awesome PO will be proficient in all three domains and be able adapt style, questions and focus, depending on the situation.

Technology Domain

The dogma that a PO should be able to code is less prevalent today. However, I do believe a PO should have technical credibility and be forbidden from using the phrase “I am not technical”, in order to shrug the responsibility of understanding the technical implications and impact of their decisions. They have to be technical enough to ask great questions to the technical teams, and be able to push back if the technical team say “there is something wrong with the left phalangee”. I agree that the PO does not need to code, but they do need to understand how their product hangs together, including the names of the key systems and what they do. Coupled with this knowledge, the PO should also have great relationships with Solution Architects and Business Analysts (the PO’s best friend), to validate their ideas and the impact on the wider ecosystem.

#POHack: To aid my knowledge, I tend to printout the solution architecture and bring it to all discussions with the team. I also run “geek-beat” sessions with the allure of coffee and cake, where development and wider team members can discuss how the product works.

User Experience

As the voice of the customer the POs should be obsessed with the user experience. The user experience includes, but is not limited to, the following: visual identity, screen flows, end to end customer journeys (happy and non-happy paths), error messaging, tone of voice, operational support, data and marketing. The PO should ensure the above are complementary and support the customer’s goals, and also explore edge case scenarios.

To bring this to life, I want to share a bad user experience with you. On a recent online Christmas shopping spree, at the check-out section, I got a message, “An error has occurred. Please try again.”  I tried again and everything worked. The next day I saw that I had been charged twice on my credit card, however only one product had been dispatched. After waiting for 40 minutes to talk to someone and being passed via a few people to ‘an authorised person’, they rectified the issue and refunded the erroneous payment. Clearly the end to end customer journey had failed. Instead of complaining, it was my PO duty to suggest some improvements. I suggested a monitoring mechanism be put in place so that if the customer has two transactions of the same amount within a time tolerance, or an error occurs, then a workflow ticket should be generated. A customer agent should then proactively contact the customer to confirm transactions and have the authority to rectify any issues. I also suggested they map out all their journeys, and use data to understand the pain points for customers. To my earlier point, feedback mechanisms need to be embedded, to ensure the voice of the customer is heard and acted upon.

#POHack: I have built out a network of great UX and UI friends that I bounce ideas off. I test out customer experience from many industries and share my thoughts and screen shots of apps into a shared UX and UI Slack channel. This keeps me aware and generates new ideas on the latest trends and offerings from competitors and from other industries.

Business

In the business domain, the PO ensures the product adds value and aligns to the business objectives. This is achieved by owning the vision, business case, product development and KPIs of the product.

– The PO takes the product vision from concept to customer, by marrying the customer needs and business goals into a coherent vision. They do not necessarily have to create the vision, but are responsible for ensuring a shared understanding of the vision across all stakeholders. The POs communicate the product vision not just by long Martin Luther King type speeches, but also by visualising these on a story board and sketches. The vision should include the problem that the product is trying to solve. I tend to create a hypothesis as my vision statement and test the hypothesis with focus groups to validate the vision. Testing the vision early enables you to answer the key question of the product: Who is the product for? What problem will it solve? and, Why will the user want to use the product? One thing to note here – the vision is not fixed. It will change with time and the PO should always be course correcting the vision against the ever changing world.

#POHack: To ensure revalidation of the vision for new products, I have a SWOT of my vision on a wall, which I update every week based on feedback and market insights. For more established products I use BCG matrix in combination with the SWOT.

– The PO defines the value proposition and business case, engaging with business stakeholder to ensure business fit and buy-in. They must be a great negotiator to manage difference of opinions/conflicts across to business. Peter Drucker is quoted as saying “you can’t manage what you can’t measure.” To me this means you can’t know whether or not the product is successful unless success is defined and tracked. This is why it is important for the PO to be proficient in cost modelling, P&L, KPIs and builds, into the product lifecycle. POs do not need to be an accountant or spreadsheet junkies, but need to understand basic finances, such as cashflow, spend, Capex, Opex, ROI etc.

#POHack: Build out a library of business case templates which you can choose and adapt for each product. I have a finance mentor who reviews my approach and provides critical feedback in things that might be missing from my business case.

– The PO owns and drives the product roadmap, including management and prioritisation of the features backlog. PO should have an explorer’s mind – they should be curious and have a strong desire to innovate, take risks and think outside the box. They should have a radar view of various industries, emerging technology and customer behaviour trends; using data points on how a product is being used, to formulate innovative new proportions.

#POHack: Twitter, LinkedIn, and sites like finextra, as well as fintech podcasts, are all a great way of keeping your finger on the pulse. I schedule geek out sessions monthly for people to come together over a warm beverage and discuss latest trends and share opinions.

Conclusion

In Formula 1, the car is never perfect, the strategy and configurations change based on environmental factors and testing (the pilot). The team finely tunes the car and use telemetry data and driver feedback to make adjustments, until the car is within acceptable performance. So why am I telling you about Formula 1? Well, it’s very much like digital products, where feedback and the external environment puts pressure on the product to change. The product will never be perfect, and will require an on-going process of feedback and development.

Awesome POs are those who roll up their sleeves and help their team succeed and realise that each race is different. Although they own the product, they do not hang onto their egos, they are able to balance team dynamics to optimise creativity and productivity, whilst ensuring they are connected to the vision. A laser focus on MVP and inbuilt feedback of the product will enable product success. I love this saying by Dan North: “MVP is not the crappiest thing I can get away with, it is not shaving the requirements until they stop crying. It’s minimal viable product that will delight the user.” Remember, the MVP is only a moment in time – the product requires constant change to stay relevant. If you look at Monzo, Revolut, Netflix, Facebook, Twitter and many more, they are continuously updating their product to refine it, as well as add killer new features.

What is your professional calling in life? People who know me will agree I am a bit of a geek, with a great passion for digital products and user experience.

As always, I welcome your thoughts and opinions – if you are a PO, and think I have missed anything out or want to develop any points further, please get in touch.