I began to suspect I had fallen into the same “simplicity” trap that many do when they use the word platform. This platform product manager role was not in fact managing one product, but instead the 4-5 separate products that comprised the platform. It was only once I dug into that level of detail that I felt I could fully describe the role. (View Highlight)
My point in writing this is to elevate the importance of discussing if something should become a data product. It is really tempting to automate everything, to democratize a capability, so to speak. It is much harder to say “I don’t think that’s the right investment for us, let’s keep doing it more manually.” But for many companies and organizations, that might be the right answer. (View Highlight)
Let’s put aside the idea of persona, user needs, understanding the business problem and getting stakeholder buy-in. While those are hugely important for creating a useful data product, I’ve previously written about the pitfalls of not accounting for these components in a careful, methodical way. Instead, here are a few situations where the design of the product itself (more backend than frontend for now) is the bottleneck for growth and adoption of the product. (View Highlight)
In these newsletters, I typically try to include 5 points or things to think about. But today, I’ve just got one: look at the product you are responsible for. Look at the list of things you wish could be better about it. Then cut that list down to 1 thing. Yes, just one. It might not have anything to do with improving the data and everything to do with the product experience itself. (View Highlight)
Why am I taking the time to say all of this? Because the key to being a data product manager is knowing when it isn’t all about the data. At some point, you may get no improvement from technical enhancements. In the coming 12-24 months, we’ll only get to do fewer things, not more. It won’t be all about the data, even if your job is to own a data product. (View Highlight)
Personas are general representations of a user or customer. We build personas to represent different user types and characteristics of those users that use the product we build in a consistent or similar way. People are not personas. An individual person is full of nuances and unique background, intentions and training. We need to actively create personas, we do not just “find them”. (View Highlight)
This desire to help without thinking about personas is exactly where data products go off the rails. (View Highlight)
The builders of the data products are well intentioned. They are trying to do their best. They are listening to customers. It just happens to be the customers they are listening to are the loudest in the room and often those they are most familiar or comfortable with in the organization. We need to work actively against this tendency. (View Highlight)
Spend time defining the key personas in your organization that use or are impacted by data products. It is much easier to define these personas upfront that do it in an intense moment of planning or prioritization where time and patience are often much lower in availability. If you have these personas and socialize them in your company, you’ll be much better off when it comes to hard decisions. (View Highlight)
Push actively against the “Person X wants us to build Product Y” mentality. Many organizations I have been a part of justify product decisions with a name of someone who wants it, rather than the personas that they product actually serves. Specific people and decision makers are temporary at companies, but personas are long lasting. Ask about the persona. This is where having the personas laid out already pays off. (View Highlight)
It sounds simple to say focus on the persona. But power structures in an organization are a very real thing. It is hard for a data scientist or product manager to tell a VP that the product doesn’t clearly address a persona. This is where leadership matters a great deal. If you want to see change in this space, it cannot just be put on individual contributors. Leadership needs to sponsor these ideas and these processes. (View Highlight)
If your company deprioritizes an area of investment, think about how your product investment should reflect that (or not). It is really common for a company to pivot investment in an “area” (which might be a key persona for your product) but the rest of the company does not quickly update to reflect that pivot. Specifically, you might have close relationships with key stakeholders who tell you “yeah, that isn’t important to the company, but I need it to do my job.” Be very wary of this type of situation. By focusing on people, it is easy to get confused about “what matters”. By focusing on where the company is headed and how different personas are part of that, it is easier to think less through the lens of working relationships and more through where the company needs to go. (View Highlight)
