Outbound Product Management

Wearing multiple hats is common practice in the modern organization, and no more so than in small companies. In the marketing domain this can mean outbound product management is either merged with inbound or occasionally lost all together. This post looks at a number of reason why outbound product management should be of equal if not more importance than inbound; especially when you consider the success of your product or service often depends on its penetration, adoption, and usage.

Consider these quotes from some of the leading experts in our domain:

  1. Executive Chairman of the Board at Google, Eric Schmidt (Ph.D) stated at Salesforce.com’s Dreamforce 2011 (see 0.33.47), “Apple proves if you organize around the consumer the rest will follow. And that’s something I did not understand until Google. Google runs in a similar way. Try to figure out how to solve the consumer problem and the revenue will show up.”
  2. In a July 2011 Ted Talk economics writer Tim Hartford shares the surprising link among successful complex systems – that they were built through trial and error.
  3. David Heath, Vice President of Global Sales at Nike inc. (ret.) stated in 2011, “the days of relationship selling frankly are over, and the days of bringing in the solution to the buyer and doing the buyers work for them are going to separate the winners from the losers.” See Developing Challenger Sellers – a new book from Corporate Executive Board.
  4. Marc Benioff, Chairman and CEO of Salesforce.com starts all his keynotes at customer events such as Dreamforce by thanking the attendees – the customers for making Salesforce.com what it is today.
  5. Caroline Michiels, of custom software business ThoughtWorks stated, “60% of functionality in packaged solutions is never used.”
  6. Mike Heilman, a former colleague and veteran sales leader, responded to the HBR article, “Are top salespeople born or made?” I reposted on LinkedIn stating, “I have seen people of many, many different personality types succeed in sales. I believe that the only absolutely required characteristic is empathy. You simply must be interested in other people or they will reject you. Humor and intelligence are really good as well.”

While each of these quotes are recent, they are also pulled together for this post from different sources. The context is different, yet they all have a consistent theme – listen to your customer.

What can we take away from this when bringing new products to market? Here are a few questions worth considering:

  1. Does your product or service address a customer need and also the need/s of prospective customers – i.e. market needs? Which well known need/problem is it addressing? Have you defined the opportunity upfront? Think how Google took on Microsoft Office with Google docs – significantly less functionality yet with an unmatched collaboration capability addressing a well known market need. What are the 2 key points you use to market your new product? Forget features – can you frame the issue in the mind of the customer?
  2. Have you built a business model including market share? What are the objectives? What does success look like?
  3. Are you able to synthesize what you have heard in the market, communicate this in the user stories, and ultimately simplify your product offering tailoring it to resonate with your customers?
  4. Are you confident you have provided your salesforce with the right material to enable them to target the right buyer and subsequently empathize with the buyer? Think buyer scenarios (like user scenarios but focused on the buyer – profile and pain points) and customer success stories (or testimonials) which enable the sales team to identify the right buyers, teach the customer something new about their business and take control of the sales process. This is such a critical step. If sales are unable to penetrate accounts, you risk the team dropping the new product and falling back onto others which have historically delivered (won business) for them.
  5. Have you set your new product or service up for success? Recognizing adoption is key and iterations will evolve – think Google Docs, Google Mail and more recently Google + which all launched with feedback mechanisms, and a dedicated team behind the product enabled to release iterations based on the feedback. Eric Schmidt also said at Dreamforce 11, “…you are much better off if you organize around a continuous iteration model”.
  6. How will you react to a competitive play?

Does goto market planning start before or after development in your company? Does your company separate many of the outbound product management functions into a Product Marketing function? What questions do you ask when developing your goto market strategy? Use the comment box below to share your experiences.

Agile and Product Management

The purpose of this post is to provide an insight into working with Agile from a Product Management perspective. Given Agile recognizes Product Owners not Product Managers (more on this follows) the prevailing challenge we’ve faced in Product Management is time.

Below are 6 recommendations for a Product team to ensure true product management continues.

1. Change approach and find the right balance

First and foremost when your development team switches to Agile, the product team also needs to make changes (or risk drowning). Assuming the Product Managers perform the tasks of a Product Owner, its important to remember these responsibilities are a subset of the overall responsibilities of a Product Manager. With tight deadlines being an inherent characteristic of Agile, planning next months sprint along with performing tasks in the current sprint can quickly absorb all the hours in a day leaving little time for the other functions in Product Management.

Finding the right balance between being available to perform the responsibilities of the Product Owner such as:

  • creating and maintaining the backlog
  • prioritization according to business value or ROI
  • conveying the vision
  • representing the customer
  • participating in daily scrums / retrospectives and sprint planning
  • inspecting the progress and subsequently accepting or rejecting the deliverable
  • communicating externally to all stakeholders etc.

and executing other inbound and outbound Product Management responsibilities such as:

  • understanding market problems and your companies unique ability to address them
  • creating an integrated product strategy
  • formalizing plans to deliver profitable solutions
  • translating plans to user stories for technical implementation
  • creating go-to market plans aligned with the buying process
  • ensuring organizational readiness to sell and support deliverables
  • supporting the sales channel with market and product expertise
  • not forgetting bugs, meetings, webinars and of course powerpoints

means creating an environment where Product Mangers are not involved in every single tactical decision. This is an important step towards a successful implementation of Agile within your company.

2. Build to scale 
One of the greatest aspects of product management is the cross functional interaction. Throughout my career I’ve thoroughly enjoyed working with customers in addition to every single function in an organization – from Legal to Finance, Sustainability to Operations, Marketing to Sales, HR to Client / Customer Services in addition to Research and Development and Executive roles. Product literally touches them all. This however can also be one of the greatest challenges as each of these groups has a different view of what a Product team does for example:

  • Sales require support for RFPs (often with tight deadlines), pitches and ad hoc meetings.
  • Marketing require product insight for positioning and pricing.
  • Executive team require a product portfolio which meets the overall company goals, in addition to justification in the form of detailed market analysis and a well thought through roadmap defining the path to get there.
  • Development/engineering require the PM to be Product Owners (this can easily become a full time role given monthly sprints and releases).

As the Product Manager goes about their day skillfully switching conversations, between customers, executives, engineering, sales, marketing and client / customer services to name a few, it’s possible to see how the responsibilities of Product Managers are not insignificant. As an example conversations may range from:

  • competitive landscape and analysis to build, buy or partner decisions and goto market strategies,
  • business cases and driving ROI to portfolios and roadmaps,
  • star wars, black holes and unicorns to personas and user stories
  • value based selling and understanding market problems to pricing and positioning,
  • thought leadership and support to training and collateral.

Each of these responsibilities demands time and more importantly a detailed understanding. Ironically with all the meetings, coordination and communication these responsibilities bring, being available to each stakeholder group and department often places challenges on the product managers time given the accelerated timeframe and demands of the sprint.

Depending on the size of your team, think about supporting roles such as Product Marketing Managers, and Product Specialists who can support Product Managers and provide the appropriate coverage to ensure a well delivered and adopted product. Helping everyone understand the domain so you don’t need to be involved in every decision is also of value.

3. Don’t short change market research
Research (competitive, market and end user) is a source of credibility for Product Managers. As mentioned, an Agile environment will create new demands on time which may well eat into research time which was previously accounted for in the creation of the large business requirements specifications/documents.

Work to find solutions to avoid this, for example – share your research and create many voices for it. This will help free up time as good product management begins before a user story is written. It always starts with solid research – understanding the market problems, assessing the competitive landscape and identifying opportunities to differentiate. Support qualitative research with quantitate.

When conducting research, a Product Manager is looking to answer a number of questions:

  • How does this product become part of the everyday workflow of its user base?
  • What are the needs of the untapped or potential market?
  • How can we differentiate?

This level of understanding takes time, do not short change your research time which ultimately is paid off in the clarity and robustness of user stories. Some of the best and most successful sprints at Toolbox.com have been ones following several months of research by the team.

4. Be prepared to validate 
Armed with this research and analysis, the Product Manager arrives at the table with a wealth of information valuable to each of the groups mentioned earlier. For the executive group it includes direction and insight into the roadmap and definition of the market, for sales and marketing this includes critical research for positioning and placement. For development/engineering this includes the very validation that is demanded often so vigorously in an Agile world – and rightly so. It is neither fun nor efficient to change direction based on a miscalculation once troops are mobilized.

It’s very healthy to work in an environment where teams challenge each other. If this isn’t the case, look to foster this type of environment certainly within the Product and Development groups. Developers bring strong product and environment knowledge to the table and will either help shape a solution to be more robust, or recommend alternatives which may better meet business goals.

This type of validation is paramount to the process – with finite resources, time bound velocity, competitive pressures and business goals – focussing on functionality which does not drive the business forward is not an option. This type of validation provides a valuable check and balance.

5. Avoid feature bloat 
In an Agile environment it is very easy to bloat products with features as there is a tendency, and organizational, desire to keep development busy. If you are not ready – try handing a sprint over to the dev. team to focus on bugs, infrastructure or technical debt.

In the case of a launch, being ready means understanding:

  • the goto market strategy
  • how products drive returns to the business
  • and how a product fit into the business model

Defining a model to score requirements will help you understand and rank what delivers the highest return for the least effort. We’ve invested velocity recently removing features resulting in significant improvements to user experience.

6. Over communicate
Agile provides quick iterations – it moves fast. Supporting functions such as Marketing and Design, require insight and runway to ensure plans are executed. Sales often need training and collateral – getting the latest information to the front line will likely help close deals. A Product team has the luxury of knowing most if not everything which is taking place within the sprint and is responsible for external communications. The accelerated pace significantly increases the need to keep stakeholders regularly informed. It is easy to assume everyone else is on page when this might not be the case. Other teams may not be able to support a release – this information upfront will help with planning.

Share planning, go to market strategies and roadmaps frequently. Articulate the market problems to all stakeholders (Sales, Marketing, Executive and Development). Get everyone aligned and work to enable these groups have sufficient information to answer their own questions.

Product Managers need to be scalable. Providing the context of market problems along with evidence of this problem in user personas and scenarios enables a development team to go above and beyond producing great products.

Hopefully this posts provides some valuable pointers for any product team looking to transition to Agile alongside their development team. I’ve certainly enjoyed the transition from waterfall to Agile and learnt some of these lessons along the way. Please share your thoughts using the comment box below.