Every time I take over a new product development team, I keep asking my self: how do I start, what should I build, how would I know if I am on the right track. Most of the time, my answer would be…. I don’t know – not until I fully understand what the main problem is.
As a product owner, to be the user of my own product would be the first thing I do every time I work on a new theme. If the product is completely new, I will find the closest competitors and use it. It is usually simpler when your product is something that solves only one specific problem, such as ecommerce platform because it doesn’t take long to try the whole user journey from one funnel to another. However, when the product is designed to address operational issue (e.g. automated business processes or monitoring tools), it might take longer time to be the end-to-end users, simply because I need to ‘act’ as many different business units. Above all, I need to understand the problems for each unit. It takes weeks – if not month – to just become the user of this type of product, leave alone to completely understand what’s going on and how each unit operates, especially when it involves global operational chain.
So when people ask me if there are any similarities and differences in building something for digital environment and operational team; I would say, yes – there are basic fundamentals to build a product and also yes – there are differences in how to implement and test it.
In my opinion, product is a product. It bears the same fundamental: to solve users problems and help them to do their job easier (if not better). The main question in building a product is what’s the job want to be done (PS. check value proposition design book for reference). Thus, when you have so many different stakeholders with hundreds of different requests, you need to ask them ‘what actually do you want to do with this?”. Keep this in mind: people have a tendency to come up with solutions which necessary not the best way to solve their biggest problem (plus… it is well known that most of the time users don’t know what they want), it’s our job as a product owner to choose what to build that is most beneficial for the business. So, to have a deep understanding about what they actually want to do is important. More important, though, is to understand how it is beneficial for the business. Be careful with a pitfall where we actually just help them to do their job without adding any business impact. Nothing wrong with this (especially if the effort is low), but make sure to set the priority right. This business impact evaluation holds the same principle regardless what you want to build.
At the same time, always understand the development aspect well. Some developers tend to exaggerate things and some tends to guess without understanding the details. Sadly, before working with them, it’s hard to measure what they define by small or large task. In my opinion, the best thing we can do is to take reference to one of the story and start from there. Talking about development sizing, I personally believe a good technical knowledge is a huge advantage for a product owner. It doesn’t mean that I have to code but as simple as understanding the limitation and how things are built would allow me to detect in early stage when things go wrong. This knowledge also helps me to know when I have to be pushy or give them time regarding a story. One thing to remember, when building something that involves offline procedure and products, always remember to put the operational cost in to equation. There will be people who need to build communication scheme, implementation details, and offline procedures. This, most of the time take more coordination, time, and effort than building something in the digital world.
Then, as every other prioritization process, these impacts and potential cost should be the most important aspect for my equation in choosing what to build. In practice, I always see how strategic alignment and human resources become other two big aspects in prioritization.
With the same basic fundamental, the main different in building a digital product (such e-commerce platform) and product for business processes is in the testing process to measure success. Unlike ecommerce website where you easily run tests (ie. A/B testing or multivariant test), due to its nature, I can’t really run A/B testing on operational. Not only because it’s way harder to A/B test something that people use on daily basis for their work, it is also almost impossible to create 2 different procedure for the global offices without creating chaotic situation. On top of that, there is no 100% guarantee that people will do the instruction precisely. This uncertainty may cause a bias for both control and test group. Thus, most of the time, when I need to roll out a new product for processes, e.g. software for claim approval process, I need to roll out without A/B testing it – then judge the success afterwards.
Don’t get it wrong, it doesn’t mean that I don’t test the product before roll it out. Whatever it is, always test your product. Let it be a beta testing for small audience or hire bunch of testers to do bug bash, there has to a test before implementing the product for a bigger audience. What I meant by ‘test’ on previous paragraph was A/B experimentation where I split the audience into 2 groups (i.e. control and test) at the same time.
The last part is metric. How would I know if my product is a good one or not? With A/B testing, as long as clear metric(s) is chosen (e.g. buying conversion or open rate), it is easy to understand the direct impact of my product. This happens because both control and test group experience things at the same period of time. On the other hand, without A/B testing, there is no such benefit. Thus, it’s important to pay more intention to co-variant (e.g. event, seasonality, etc) when A/B testing is not present. Launching a food delivery platform in summer might have different result with launching an the same product in spring. In any case, I believe choosing the right metric in advance is the most important part. I always try to set main metric and some supporting metrics before launching anything so that I know if this ‘solution’ fits the problem I want to solve or not.