Minimizing effort and maximizing outcome

I've been a product manager for a few years in different companies. It's been an awesome trip. I've never been so much of a marketing or sales oriented than technical gimmicky person, but have been learning a lot after understanding that everything revolves around adding value to product users according to company strategy. It's not an easy job in any way, there's a lot of things you have to take into consideration. In my early phases I loved to tangle to features that I feel like "diamonds", that are new and innovative, transitioned from that mind set to creating good overall experience from marketing to support. There's not much of product management training or schools, a lot of us are self-taught, it might take the time until companies understand the value of good product management and what it consists of and the training will follow. Thought to share my trip and lessons learned here.

Don't believe yourself, instead do the right things

For me the one main things I've learned in the last years is that doing the right things doesn't mean you do the things you think are right. It has taught me that even how correct you think you are, ALWAYS try to fail fast. It sounds a bit harsh that you do everything to fail it so don't get me wrong. The idea is to learn as fast as possible to gain new insight of how things should be done so you can change the direction fast if you see it going in the wrong way. In product management I'd try to fail in every stage, especially in discovery phase and before discovery when you're just thinking of doing something in the future. The earlier in the process you see that you were wrong or the plan didn't work, the more you can put effort on doing the right things. Popular ways of "failing fast" are things like prototyping, pretotyping, concierge MVP, A/B-testing, ghost buttons and wizard-of-oz MVP, all of them are just methods of gaining insight of "will this work or fulfill it's business value?" before even a line of code has been written or production lines have been tested. Don't skip it even though how right you think you are.

I love the fact that when I talk to users, they usually go through their ideal situation and tell you how the software should work. Don't believe them straight away. Customers are too good to give you definitions instead of real customer needs. Instead try to find out the root reasons WHY they want things to do how they are suggesting, keep them away from your product and try to find the main motivation. It's easy, just ask "Why?" until you find the root reason. The customer might even think you're a bit slow (so to say), but keep asking. When you get to the root reason, you know what is the one thing that would maximize the outcome. Now you can define the minimum viable experiment/MVP, prototype it and improve it phase by phase. This way you won't be doing what the customer said, since it usually isn't the thing they wanted. Now you're maximizing the outcome.

Know your users

When we think of it, a product is as good as how it serves it's customers. Also it should give revenue to the company that creates it, otherwise it won't live long. A cold reality to everything is that don't fall in love with the product, remember that everything revolves around money. Every action you do should produce revenue. And revenue comes when your product serves your customers in the best way possible. To get to know your users, you really should start thinking about the user - I mean really. Analyzing the business data from Google Analytics, usage log DW's or any other way can give you some sort of insight about what is used and how it could be enhanced. Also it's a great tool to spot user actions, return rates and so on. But analytics doesn't tell you why your customers use it, for that you need to really dig into your user's brains. For that I personally use different kinds of service design methods, like shadowing and user journey mapping. Also things like storytelling workshops are a great asset if you have a possibility to incorporate several user segments in one. From workshops and shadowing I've got information that has shown that some of the features are used for example as workarounds since the implementation is too hard to use or some process wasn't actually like we imagined.

You should at least have a larger view of what kinds of roles or users use the product so you can segment them for marketing and sales. Also any content can be created to guide the user to do right things they want to do. I personally like user personas and buyer personas that have been thought of. Usually the buyer in b2b isn't the end user, so don't forget him/her ;) User personas are a profile of user group that shows what drives them to use the product and even show her/his motivations to use the product. Nowadays I'd prefer creating personas as short as possible so you can remember them. If you need demographic information, use it, but if don't, scrap it. Keep the personas as short as possible, but try to retain the info about the user: what motivates them to use the product. In B2B it's not a bad idea to create personas for the customers of your customers, since it might reveal the motivation that drives your customer's personas. After creating personas, keep them along all the time when developing a feature. Always think about what would this persona do in this situation - and you go a long way. This is also the way to target your product to certain user groups if necessary. Really useful tool.

Share

Most of the time you're with your beloved product team, but for the product to succeed, you need to get and give input to the rest of the customer key points in the process. There's the marketing, which usually works in the future, sales that try to create added value on the field, testing, support services and probably also logistics. Identify the stakeholders in early phases and try to keep them on track of development so they can react accordingly. I used to have a way of providing some sort of roadmap and white paper on every feature, but too bad nobody wanted to read those. So far the best were reviews and demos about upcoming features, keeping every stakeholder on the track at all times. Transparency seems to be a friend that should be used in every possible situation. Not depending on the method, it is essential to share the information so that every part of the company walks in the same direction. After all, as a product manager, it's kind of your duty to orchestrate every step along the way.

Summa summarum

So what have I learned in these years? No matter what you're developing, if it's a service, a product or let's say your a politician. There's always other people that depend on you and you are depending on, so know your stakeholders and create shared understanding between them. Know what's the strategy you're all driving to. Know your customers, since your customers provide you the revenue, the easier your product is to buy and use, the easier it's to get customers. Happy customers probably recommend you further. The more you know about your customers and WHY they do things the way they do - what motivates them - the more you can provide added value to them. And if you do it by failing fast and defining minimum, you're probably maximizing the outcome or at least not doing things in vain.

And yes, this is something I've learned through the years. It isn't magic, it's about maximizing outcome with minimum effort just by keeping a tight eye on the customer and users and sharing the info with everyone else. Laziness is a virtue ;)