To Make a Great Product or Service, Stay Away from the Office!

I once worked as a product manager for the world’s 9th largest software company. When the VP of R&D came to town, if you were a product manager, you did NOT want him to find you at your desk. He wanted the 40+ product managers out in the field meeting with current customers, potential customers, or with implementation partners. That was the only reliable way we, as product managers, could really understand the business problems our solutions should be addressing. If we were staying in the office, relying on our own expertise to decide what the product or service priorities should be, then we were, as the VP put it, “Just MSUing.” That’s short for “making (stuff) up.”

And he was right.

You need to see, firsthand, what business issues a broad spectrum of your customers and constituents are trying to solve. The more instances you see, the better. This gives you real, objective data for evaluating and prioritizing your backlog. You’ll always have “the” customer that is the most politically powerful or biggest revenue generator, but catering too much to their needs is ultimately a mistake — unless your goal is to be outsourced IT to that group. If your goal is to provide a solution that serves the most users and provides the highest value tools, you need a solution that meets a spread of users’ needs (without diluting your key value, of course).

Even if you have SMEs (subject matter experts) in house, relying solely on them is also mistake. Just as overvaluing your key client is dangerous, so, too, is relying on your SMEs as the canonical source of input. Sometimes their experiences don’t give you the whole picture. SMEs often come from the more advanced/enlightened organizations. How are you getting info about “normal” constituents? Getting more experiences helps you validate what they’re saying and helps you find all the nuances.

Talking to lots of users helps you better abstract out the business problems your solution should address. A broader understanding means you’re more likely to understand if what you really need to build is a dog door. Sometimes a client (or SME) might tell you they need a door with two handles on each side: in addition to the round knob already in place, they also want a latch-style handle installed below the first one. After more prodding you’ll learn that the person wants that second handle because their dog can use a latch to open the door, but not a standard round knob. By further extracting the business problem, you will eventually realize that what the person really wants is not a way for the dog to open the door, but a way for the dog to go in and out by themselves – a dog door!

This advice is broadly applicable and useful even if you’re not a product manager. Are you building an IT service? Do you really understand the implications of policies and procedures that support that service? Are you catering to just the key constituents? How will your decisions affect other users and departments? You may still focus solely on enhancements that support that key user, but at least you’ll know the implications for other users and can plan for how you’ll support them.

So, leave your desk, go meet with your constituents, and stop MSUing.

Tony Navarrete is a freelance writer, international bicycle traveler https://itinerantphilosopher.org/, who is also a thought leader in IT business management strategies --- https://ephemeralphilosophy.com/