January 28, 2019

Please reload

Recent Posts

The Buggy Whip Companies About To Be Undone by Cloud Computing

January 1, 2019

1/3
Please reload

Featured Posts

Structured for Growth - "Product"

February 19, 2018

A relatively new term used in growth technology companies, particularly those with a software focus, is “Product" - a combination of product strategy (pricing, packaging), product management (market problems, requirements), and product marketing (competitive intelligence, sales enablement, go-to-market.)  In this post, I’ll first describe each of these product roles and then some lessons-learned both inside Product teams and between teams within the same company.

 

 

Product Strategy

An effective product team will be comprised of individual contributors at every level, and even as an organization scales, I have found it helpful to maintain individual contributor responsibilities in people-management roles.  As such, the role of product strategy usually falls to the senior member of the product team.  This person, working from the perspective of decades of experience, should own the pillars of a company’s product strategy, usually together with the President, and specifically the next-layer execution of that strategy including the refinement and care for pricing and packaging.  A good friend that ran a Microsoft business unit once told me, “the smartest people at Microsoft aren’t in software development, finance, or sales – they’re in pricing and packaging.  That is Microsoft’s special sauce.”  Getting this right is one of the most important levers an organization has to increasing profitability.  A product strategy owner will decide, for example, whether to offer a product in good/better/best packages, or another form; whether to include certain features in the base product or offer them for upsell; purchase minimums and step functions; below-the-line fees and cost recovery items; volume discounts and channel margins; and even have input into the sales compensation model.

 

Product Management

In organizations in which the main product is typically software-based intellectual property, product managers have a critical role in the long-term value creation of the business as a whole.  At the most basic level, a product manager owns the market problems that products address.  These market problems (not a particular customer’s problems, but the problems shared by a collection of all current and future customers and prospects) drives the marketecture of a product – the ways in which a product addresses those problems.  This important pre-work for any product is informed by constant outside-in interactions, looking outside the walls of the company for the right answers.  This is so important I’ve driven home the term NIHITO with product teams in the past – Nothing Important Happens In The Office. The next layer of responsibility for a product manager involves defining – in great detail and in partnership with an engineering counterpart – the product requirements and prioritization of workloads to solve a market problem and offer the features of the product.  And this is where it stops.  It is critically important, in my experience, to put Product Managers in the role of “what” while engineers own the “how.”  This means Product Managers don’t write specifications, don’t act as agile team leaders, and don’t ever have engineers reporting to them.  Instead, pair a product manager with an engineering manager, and ensure that both personality types and responsibilities up and down the organization are clearly defined.

 

Product Marketing

In organizations that have reached a certain scale, typically above $30M in revenue, it makes sense to start specializing Product Managers into either a Product Development Manager (focused on requirements and prioritization of engineering workloads) and Product Marketing Managers.  Product Marketing is typically responsible for these three areas:

  • Competitive Intelligence.  The product organization in general, and this role in particular, must be the expert on your competitors: their features, packaging, pricing, analyst coverage, tradeshows, people they are hiring, online reviews, and more.  This information becomes the foundation for marketing programs, sales training, and ultimately the differentiating features of your own products.

  • Sales Enablement. Sales organizations are most effective when they have the tools, knowledge, and programs to support their efforts.  Product Marketing may be responsible for either contributing to or leading a sales enablement effort with tactics such as developing and promoting freemium mini-products or features, creating customer success stories or case studies, delivering sales training on differentiating features and customer value points for new hires and upon new product releases, helping the marketing team set up email-on-behalf-of nurture programs based upon customer lifecycle stage in the company’s CRM system, and organizing and distributing content to the sales team through an authoritative and easy-to-access portal.

  • Go-To-Market. When a product is first released, or when subsequent product updates are released, a flurry of activity must be managed in order to land that release effectively.  In the past, I’ve used a checklist format to identify these activities, but larger organizations would benefit from a PMO resource and formal project plan to keep everyone on track.  Consider, for example, a major version release of an existing product to a customer base of 1,000 clients with an ARPC of $3,000/month.  Perhaps this release contains a new module, a handful of new features of existing modules, and 50 bug fixes.  Once the engineering organization is ready – the development is done, QA is complete, and a production infrastructure release date can be scheduled – a lot has to be done, and the Product Marketing lead is responsible for making sure it gets done as well as individually completing some of the tasks.  An example is below. 

 

Product Lessons Learned

When well-designed and implemented, a product organization can be the most significant contributor to long term value creation for your business.  Here are some lessons I’ve learned from various product teams in the past.

  • Role clarity.  It’s important that your organization understand the role of the product team – specifically that they exist independently from the engineering organization and own the “what”, not “how” to do it. Establishing role clarity will avoid missed expectations later and help ensure a great working relationship at all levels of both the product and engineering teams.

  • “Managers.” Product managers and product marketing managers typically do not manage people, they manage products and processes.  Don’t burden your product experts with people-management.

  • Swim lanes. Organizationally, a software company must be set up to simultaneously execute on several different categories of work – each in their own swim lane – at the same time.  At the very least, you must work on new feature development while simultaneously fixing and improving existing features.  Ideally, this means separate development teams with a constant rotation of engineers between teams to keep them fresh, but it could also mean timesharing among a single set of resources.  In more complex organizations, you may have several swim lanes – each with its own burn-down list prioritized by a product manager.

  • NIHITO.  As I noted above, Nothing Important Happens In The Office.  You must constantly drive your product teams to interact with those outside your company.  In its simplest form, this could mean ensuring that your product managers speak with customers on a regular basis, conducting interviews themselves.  Don’t let them outsource this or structure your company to insulate them from real customer interactions.  It also means maintaining a 360-degree view of the market, attending competitor’s demonstrations, speaking with analysts, and engaging with key prospects alongside your sales team.  A product team that doesn’t talk to people outside your company is not a Product team.

  • Runway. Product people, by charter, are focused on long term value for a company, and as such should be primarily measured by long term KPIs.  For example, whether or not a particular deal closes in March or April is completely unaffected by the Product role, so new logo MRR in a particular month is not an appropriate KPI.  However, the successful development, release, and landing of new product features should have an MRR impact several quarters out.  Another example – getting listed on Gartner’s Magic Quadrant may take a product leader half a year of analyst meetings, relationship-building, and product development, but once listed might mean your company’s win rate increases by 20% among enterprise customers.  Make sure you provide your product team with sufficient runway to have an impact.

  • Recruiting.  Great Product people tend to share some traits.  For product managers, I tend to look for people with both seniority (gravitas, the ability to command a room, to speak with confidence and authority, with a track record of doing so in the past) and being an individual contributor (not just a people-manager.)  This is a tough filter, as many talented folks would have been promoted into managerial roles, and many of us have been trained to associate success with the size of the organization that reports to them.  The next filter is on technical experience – life is easier when your product managers already understand both the technology you use and the market you’re in, because they have to become the experts in your company quickly.  Last, I’ve found that successful product managers are likeable (they get along with different personalities), humble (they truly respect the talent of their peers, especially engineers), and really fast learners.  Don’t settle for seat-fillers – this is a team you need to fill with “A” players.

  • Training is available.  Organizations such as the 280 Group and Pragmatic Marketing have very effective product manager training resources available, and some even offer training and ongoing learning for other parts of a technology organization as well, such as agile development teams and marketing teams.  You don’t need to go it alone.

 

 

 

 

 

 

 

 

 

 

Please reload

Please reload

Search By Tags
Please reload

Follow Us
  • LinkedIn Social Icon
  • Twitter Basic Square
  • Google+ Basic Square
  • YouTube Social  Icon
Archive

Subscribe for Updates

Copyright 2012-2018