There are a lot of potential pitfalls that threaten our success as Product Manager — but by far the worst, in my opinion, is falling too much in love with your own ideas, whether those are problems, solutions, or even assumptions about the market and our customers. While I think they take it a bit to the extreme, Pragmatic Marketing does have a point when they say, “Your opinions, while interesting, are irrelevant.” It’s in our nature to make assumptions and inferences from what we see going on around us — to create plans in the face of uncertainty and to identify potential opportunities that others are missing. But we do so at the very real danger of drinking our own product’s Kool-Aid and thinking that we have the one true solution and the one truth in the market. But in reality, that’s never the truth, and we need to check ourselves every single day against this danger.
This is the first in what I hope to be a series of PM 101 posts, wherein I focus on some fundamentals of Product Management. For this first article, I’ve chosen a topic that’s near and dear to my heart, as well as one that’s been raised several times during my teaching sessions at General Assembly — how should Product Managers work with Designers. Now, to clarify I’m using “Designer” as a catch-all term to include everyone involved in the User Experience, User Interface, and Human Interactions side of the product equation — basically, the people who are trained to define how the user interacts with our product in order to achieve their goals. With that established, let’s explore some common issues and potential paths to success…
It’s a sad but true fact that the vast majority of B2B apps out there have traditionally focused on basic functionality, satisfying RFP checklists, and convincing corporate buyers of the value that they offer over delighting and amazing the end users who acting really interact with the product in a daily basis. Unfortunately for the companies who have taken this tack in the past, the world of corporate technology is rapidly changing, with increasing focus on BYOD, and with the increasing exposure of end users to the world of apps on their phones and tablets, the world of corporate technology is undergoing a massive paradigm shift. Expectations are higher, and the bar had been raised with regard to what users will accept when it comes to their daily work experiences.
Ironically, one of the most fundamental tools that Product Managers use every day to communicate requirements, expectations, and user goals to their development teams also sometimes seems to be one of the most difficult things to get right. Maybe it’s because many of us are used to the bad, old days of waterfall requirements, maybe it’s because our developers aren’t used to solving problems, or maybe it’s because our stakeholders and upper management expect certainty in what we’re going to do and how we’re going to do it. Regardless of the reasons, it’s absolutely essential that we master this tool and push for its proper use whenever we can. Properly-formatted, well-written user stories are the cornerstone of a user-centered design pattern — and stating a problem that needs to be solved in a way that allows developers the freedom to solve it in the way they deem most appropriate is a talent that all Product Managers can benefit from. [Read more…]
One of the biggest challenges facing nearly every Product Manager is the lack of a clearly-defined role in the organization. Even in companies that have “rigorous” organizational structures, the Product Manager often becomes everything to everyone – the hub around which all the other business processes operate. And for the most part, this isn’t necessarily a bad thing. Unfortunately for all of us, the simple fact is that not every person has talent for every single piece of the puzzle. The “marketing genius” might not know the difference between XML, HTML, PERL, and PHP; the person with the best relationship with the Support organization might feel challenged when asked to present to the Sales organization or sit on a panel at an industry conference.
It is for this reason that many companies differentiate between “Product” Management and “Program” (or “Project”) Management. And, for the most part, this makes sense – the Product Manager becomes the voice of the customer, and of the market, while the Program Manager becomes the liaison between the Product Manager and the Development organization, sometimes even taking up a role within the Support or Training organizations as well. For smaller organizations, or very niche markets, this works quite well, particularly if the Product Manager originates from the market that the product is serving. Their experience and prestige in the community provide key insights and instincts that can guide the product in its development, and ensure that customer requirements are met.
However, a challenge presents itself when this type of Product Manager needs to confirm their instincts and insights with the market as a whole, particularly in situations where the organization has decided to implement an Agile or Agile-like product development process. One of the core tenets of Agile and similar methodologies is regular review by the stakeholder, here most likely the Product Manager. But, if that Product Manager is out in the market several times a month, coordinating these reviews can become very difficult. And the product, as a whole, suffers.
Enter the concept of a Market Planner. I first encountered this concept when I was assigned to design a brand new product, from the ground up, for a niche market that sat on the periphery of my prior industry experience — it was, in fact, at the intersection of two very different markets. The Market Planner on this product came from the other side of this niche – from the other industry in this intersection. As we talked about the concept, it became increasingly clear that she was in a great position to be the voice of the market to the product, and of the product to the market, while I was the obvious choice to work on the ground, collating requirements and combining them into a narrative that we could sell to the business as well as the Development teams.
For the next year or more, we worked side-by-side — she attended conferences and engaged in panel discussions with industry leaders, feeding me detailed reports about what was working for them, what wasn’t, what their workflows looked like, and whatever wild concepts they would come up with over dinner and drinks. I would take these tidbits of information, collect them, and put them into documents that were used to explain the product to our internal stakeholders. Often, I had to tell her “no”, or put some of her requests on the backburner, for version 2.0 of the product. And she often asked for my own input on ideas, concepts, and workflows. It was a match made in heaven, and we launched a very successful product, the first of its kind in the market space.
This was a very different experience than any other I had with that particular company – the active participation of a Market Planner made a world of difference in the product. She knew where the product should go, what the specific needs of the target customers were, and most importantly provided both a vision and a plan that I could execute against. The separation of the long-term from the short-term from the execution truly made all of the difference.
What I learned from this is that every person in the broad Product Management world has their own specific skills, talents, and interests. And the most effective structure for a larger business, particularly if they’re attempting to expand into new and uncharted areas, is to engage the market in a structured, coordinated approach – have a Market Planner to be the overall voice of the market and of the product, let them set and communicate the vision; have a Product Manager who can coordinate and collate all the work and insight uncovered by the Market Planner, and let them turn the vision and plan into actionable requirements and documentation that can be absorbed by the rest of the business; and last but not least, have a Program Manager who can wrangle the exact deliverables, the schedule, the nitty-gritty resource allocation problems that plague even the best-staffed of organizations.
With a strong “Power Trio” of these three roles, there’s almost nothing an organization cannot accomplish.