Browsing posts in: Product Management

The Case for Product Management to Own the Roadmap

Most Product Management professionals believe that one of the responsibilities of the discipline is to own and control the product roadmap. In other words, Product Management decides (with the help of engineering, sales, client services, marketing, c-suite, and others) when to ship certain features. My assumptions were recently questioned when someone posed the question “Shouldn’t Product Marketing own the roadmap? They’re in charge of competitive analysis, differentiation, communication both internally and externally. Product Marketing should know what the product lacks, what competitors do better, and how the product needs to be better.” While conducting some preliminary research on my answer, I discovered that none of the blogs explain why Product Management owns the roadmap. They all take it for granted. Product Management should be in charge of the roadmap, and there are good reasons for it.

Continue Reading


Steer the Ship

“One of my clients can’t launch their AdWords campaign without this feature” — Client Services

“What feature?” — me

“Dropping pixels in the Activators. They want to launch ASAP.” — Client Services

That feature was planned for an upcoming sprint, likely sometime in Q3 2014. I had spent a little bit of time researching product requirements, but they were not polished enough to hand to the engineering team. To make things more complicated, our Director of Product Management was out of town.

Continue Reading


Concepts versus Requirements: Know your goal

As a first-time Product Manager at an enterprise software startup, I find myself spending a lot of time doing research and creating requirements documents for our product. One of the biggest challenges early on was to build a mental distinction between a concept document and a requirement document. The concept document describes the general direction for the product or feature set whereas the requirements document is much more specific — this is a document to be handed off to the engineering team. Over the course of drafting several extensive ones, I have learned that the best requirements documents have three characteristics.

1. Show as much interaction between features as possible. Even though you may miss some interactions, showing them in a format helps the engineering team work through the details. For example, we recently built a campaign reporting tool that contains a funnel. Impressions, engagements, and conversions. Engagements and conversions change depending on the goal selected by the user. When I worked on requirements for our reporting tool, I drafted a paragraph detailing the differences. I thought it would suffice. Instead, it led to confusion. The paragraph I wrote was delivered in an easily digestible way. When I wrote the specs for the second time, I provided a Google Spreadsheet that documented the different goal types and how the funnel changed. Even though the words were the same, the format changed how quickly the requirement was understood.

2. When building products, engineering and product teams rarely have the answers to all questions that might arise. Product teams especially may not be able to flag all potential challenges for the engineering team before delivering requirements. Instead of using the uncertainty as a roadblock or using it to justify additional research, a strong Product Manager will flag any potential problems when working with the engineering team for the first time on the particular product or feature. This almost guarantees that whoever is building the technical requirements for the product will have to spend less time researching. At the very least, it shows that the PM thought about the question ahead of time and tried to address it.

3. Show functionality over design if needed. A strong PM has a deep understanding of the user and should be able to wireframe a UI/UX in the process of drafting requirements. If the problem is too complex or the timeframe short, PMs should focus on drafting the “what” instead of the “how”. In these situations, PMs should work with their design team to go through UI/UX.

Concept documents do not have to meet these three characteristics. In fact, they have the flexibility to leave questions open ended and have a well thought out user interface and user experience. Requirements documents on the other hands are much more functionality documents. They exist to guide the design and development teams in the iterative process required to create a product.


Users Come First

A few months ago, Facebook announced that it would provide higher priority to “news articles” or “articles of higher content”. They also decreased the number of people a Facebook Page would have the ability to reach, effectively forcing Facebook Page owners “pay-to-play” — pay Facebook to have more of their own fans see their content.

While some argue that Facebook made this subtle but significant change to increase it’s short-term bottom line, squeezing a few extra dollars out of Facebook Page owners, Facebook made a much longer bet on the type of information people are willing to see in their News Feeds. Over the past year, content providers such as UpWorthy, Buzzfeed, BusinessInsider, and ViralNova have perfected the art of shareable information. This information is not designed for consumption. It has been created for people to share on Facebook and Twitter. Sharing boosts the distribution of content and makes it more likely for people to leave a social network to a website. The website owner, of course, earns revenue from display ads, video ads, and potentially native ads.

Facebook noticed. The algorithm change punishes “low-quality” websites and makes it less likely that users will see information shared from them. Facebook made this change for one main reason — time spent on Facebook, not to extract additional advertising dollars from page owners, though that may be a side benefit. The social network rarely makes changes that benefit its advertisers over its users. In its ten-year history, Facebook has repeatedly argued that it prioritizes the needs of its users before the needs of its advertisers. A strong user base, of course, strengthens the value of the advertising platform. During the surge of viral, click-bait, style headlines in the Newsfeed, Facebook must have noticed that people were leaving the site or app. Not necessarily to view the content but because they found the content in their newsfeed irrelevant. Facebook, like Twitter and Google, have little problem directing their users to other content around the Internet. As long as they control the entrance to other content, the company can monetize.

Continue Reading