Monday, January 6, 2020

Own Your Category With a Network-Effect Product

At the intersection of product marketing and product development is constructing a “data flywheel” business model 

I recently found myself speaking with a number of companies - in completely different industries - yet all expressing the same essential strategy: We’d like to make our product more valuable - and more difficult to duplicate - by making it constantly learn from our customers. 

I stopped to think about that as an increasingly common strategy…. And how (in contrast) I’d been accustomed to marketing products that are just a race against competitors who were adding similar features to mine. That old approach was an endless technology treadmill, constantly trying to outpace feature parity for leadership.  

My insight was that a *real* leader is a product (or service) that develops an unfair edge, a hard-to-duplicate sustainable advantage, that makes (and keeps) the offering a runaway success. The "network effect" of customer usage is how it keeps its edge over the competition.

This is how I rediscovered the notion of the “Data Flywheel”; The idea that the more relevant data you collect from users, the more you can build better learning/algorithms and continuously develop a better and more valuable product. And finally, this positive feedback is what helps you acquire even more users and defend against competitors. 

The concept of the data flywheel was originally conceived by Jim Collins, author of “From Good to Great” IMO, a seminal business book. Another great discussion of this model is from Christopher Lochhead’s podcast (#24) part of an excellent series of marketing discussions. This product-centric network effect isn’t a new concept, but definitely one I don’t (yet) see most companies pursue. With the acceptance and maturation of more Artificial Intelligence (AI) engines, I expect this trend to accelerate over the next few years.

Your customer data is value - and key to valuation 
I’ll begin with this contrast: If your business is purely transactional, if you have no ongoing relationship to customers, if your product is not constantly learning and improving from interactions, then this should be a warning sign. It's because your customers only present a single value-in-time (the moment of purchase) and that’s all. Worse, you'll eventually lose to a competitor and/or be disrupted by someone evolving faster than you.

Many in the financial industry believe that ongoing customer interactions and data have very *real* value. Consider the simplistic example of valuing a company for its customer list and their purchase history, not just for its existing cash flow. (A very good paper by Glue Reply is on models of valuation of data as an asset) Or, consider valuing a company for its customer database, not just for hardware sales… a great recent example is Google’s acquisition of Fitbit. Per Motley Fool, “...there's a lot of data in there, of course. Fitbit collects all this health data. They've been building this digital health platform, much like Apple. Both Fitbit and Apple want to help users be able to manage their health data on this platform". At the acquisition price of $2.1 billion, this represented a valuation of approximately $75/customer.... a bargain if you think about the follow-on products/services Google may be able to offer in the near future. 

I recommend both product marketing and product development need to re-think what information the company can (or should) consider collecting, using, and ultimately monetizing in the form of a continuously improving product/service... and one that can generate recurring revenue while doing so.

Where Product Marketing and Product Management might begin:

In some cases it might be obvious what information you could collect to begin to build an accretive “flywheel”. If not, I suggest bringing engineering, product management, customer success leaders, and product marketing together - for a facilitated brainstorm. 

Ideally you want to answer this: “If we just knew ____, we’d provide incredible new value and insight for our customers.'' Consider dwelling on questions such as...

  1. How could we create a better customer “network effect”?
  2. What types of benchmark customer data sets could we develop, offer, and use?
  3. If we had it, what external data would we tap into? (Or, could we partner with others to develop it?)
  4. Do our customers want to compare themselves to others? What questions do *they* ask that we could help answer?
  5. What customer information do we already have that other business (even unrelated) want? how could we monetize it?
  6. What continuously updated product feature or data would keep customers returning to use our product/service?
  7. Could we apply AI/ML to detect customer use patterns for higher-value offerings?
  8. During your session, it’s important to think outside your current business model, and even outside your current product category. Remember - you’re trying to pursue a potentially disruptive approach to an otherwise traditional product. It might lead you in some exciting directions.
Finally, you'll probably want to build a customer “data lake” (as I see it often referred to) a unique, highly-valuable collection of customer interactions, intentions and experiences. And, if used wisely, it’s what will make your product/service more competitive and sustainable. It could include customer use of your product, their interactions on your web properties, their profiles they (opt-in to) provide to you, and even related public-domain data. But choosing what data to capture is key...

A few examples to get you thinking (real and invented)
  • A software security vendor - builds a database of past attack vectors across all of its customers, including a list of previously compromised login credentials. In turn, the security software provides customers with increasingly faster, more complete responses to security threats and attacks. 
  • A network monitoring vendor - builds a customer database of network performance benchmarks and typical precursors to failures across various technical environments and architectures. It then constantly provides better predictive alerts to potential failures rather than waiting to react to existing failures.
  • A vape pen provider - through its interactive app, assembles a database of feedback to/from customers about satisfaction ratings of oils, oil vendors, and optimal devices and temperature settings for each. It also correlates age and sex of users to preferred oils, to make suggestions for future use and purchases.
  • Automobiles - Unlike traditional insurance vendors, Tesla can assemble a database of driving habits of individual drivers to create custom risk profiles allowing the company to often offer less-expensive automobile insurance than a typical broad-based actuarial tables would otherwise permit.
  • Entertainment/content providers - Netflix, Amazon, and others constantly monitor viewing and purchasing habits and demographics to recommend additional products as well as follow-on entertainment suggestions for constant up-sell opportunities.
  • Excercycles - Peloton has famously created a subscription service for its exercise hardware that gathers and constantly updates a database of user data and demographics, matches individuals for competitions, tracks improvement, and creates custom workouts.
  • Custom Sports Helmet Vendor - a custom 3D-printed sports helmet manufacturer provides a database of customer-submitted custom designs and improvements, as well as user ages and sports levels - proactively recommending new/upgraded helmets for growing and advancing athletes.
I’d love to hear how some of you have pursued a “data flywheel” approach to your product or service - and I’m sure other readers would too.

For More Inspiration…. 
Thanks for reading! 

Wednesday, November 20, 2019

Improving Your Product Marketing Alignment

Product Marketing is a highly-networked function with multiple internal touchpoints that need to be actively developed and curated

In the tech/software world, I’m often asked how best to scale the Product Marketing function and how to make it a highly performing function in a growing organization. Really great product marketers are masters of understanding the problems their products solve, positioning those products, identifying ideal buyers and personas, and knowing the overall market. But that’s only where their work begins...

Friday, November 8, 2019

Measuring Marketing is Science, Not Art.

“If you can't describe what you are doing as a process, you don't know what you're doing.”

~ W. Edwards Deming 

When in business school, I had the honor of meeting W Edwards Deming while taking a class on operations management. Deming literally wrote the book on quality and process control, and is known for his 14 Points of Total Quality Management. But only when I entered the realm of product marketing did I realize that many of Deming’s principles can directly apply to marketing process quality as well. 

As a product marketer, I’m always asked about how to set objectives, goals and actions for marketing - for individuals, for teams, and for organizations. My approach is to first ask about what the desired *outcomes* are - the OKR approach (Objectives and Key Results) and then analyze and break-down the stages of the marketing loop.  

I use a “loop” concept (and not funnel) because when marketing is done properly, it’s not a unidirectional process that ends with a sale. Rather it should feed on itself with customer loyalty and advocacy, ultimately helping you generate even more awareness.  When marketers refer to the funnel, it only corresponds to the stages of Discovery through Purchase… so if you don’t include the post-purchase stages, you’ll be blind to monitoring customer experience/use, loyalty and advocacy. Hence the value of the loop concept.

Step #1: Break down your stages / define your marketing processes

I like to use this 8-stage loop that’s specific to enterprise software marketing and purchases - but you can adapt it to your unique product/market circumstances.  In whatever manner you use it, It’s critical that your team crisply define each stage, and even the customer personas and desired interactions at each point in the loop. Work with your team to drive agreement on stages that seem logical to your organization.   For example:

  • Discover: How, when and where potential buyers initially discover your company and products; it’s your first opportunity to expose your brand.
  • Learn: Where and how potential buyers learn more in-depth details of your products and fit-for-use
  • Compare: The first time potential customers begin to consider (and sometimes demo or trial) your offering, pricing etc. in the context of your competition or other close alternatives
  • Choose: Where your decision-maker and influencers ultimately downselect to you over the competition. This could include “bake-off” comparisons, etc.
  • Purchase: When, where and how your customer (and often, their purchasing agent) ultimately transacts (with you or with a channel partner of yours). This might be a one-time purchase, a subscription, site-licensing, etc.
  • Usage: Post sale, where your customer (often many internal users) actually engage with your product - and hopefully derive the intended value you provide.
  • Loyalty: The affinity that your customers develop internal with/for the product, your service, etc.
  • Advocacy: Where, if your customers are delighted, they’ll become advocates of yours, helping drive continued discovery by new potential customers.

Step #2: Define metrics…. And team accountabilities

Once you’ve defined a set of marketing stages that aligns to your unique org, the most critical part of the process is to define “exit gates” (essentially outcome or OKR metrics) from each stage as it flows into the next. Getting these gates and metrics right is critical because they provide you with the process control and trends of each *outcome*.  In this manner you can adjust each stage’s marketing *actions* while keeping how you measure their outcomes consistent.

The example I give here is just that… your set of metrics, naming, etc. will be different.  

But one thing is important to internalize: The metrics measure the effectiveness / outcome of each stage, and *not* the activities in each stage. For example, in the “Learn” stage, we don’t want to measure the number of events attended, blogs posted or papers written.  Instead, you want to measure the number of attendees you achieve at events, blog views, and paper views/downloads. (Think content consumption not content production)

If resources permit, I also recommend that you organize the marketing organization in a way that a single person (or team) is directly accountable for the outcome metrics at each stage.  These individuals need to be singularly focused on the effectiveness - and outcomes - of each stage, working with the other teams to continuously improve the activities (and thus, the outcomes) at each gate.  

During your regular marketing and business reviews, effectiveness trends of each stage should be evaluated, and actions adjusted appropriately.  The key to process control is to precisely and consistently measure the outcomes of each stage - which I’ll explain next.

Step #3: Metric Definition

Finally, the most overlooked aspect of the process is defining exactly *how* your team plans to consistently measure each outcome. It’s not as simple - or as obvious - as it might seem.  For example, how will you count content views? Is it just pageviews + downloads? Which pages and which content? Are “views” limited to your website or will you include YouTube and 3rd-party syndicated content? And if syndicated content, then from which partners? (And, how to *they* measure “views”?)  Getting these details right and repeatable is important because these are the specific outcomes you’ll be trying to impact by continuously improving your marketing activities. 

Your Mileage May Vary
This is just an example. It will probably vary wildly based on they type of product you sell - if it’s a service, or B2B, or B2C etc, the stages and metrics will vary considerably.  My advice? Dissect your buyer’s journey into as many distinct phases as you can, and map your marketing organization’s activities/outcome onto it. That way, you can apply as much process control (and continuous improvement) as possible. 

Other thoughts/ideas? I’ve love to hear them!

Thursday, September 19, 2019

The Argument for Public Product Roadmaps

“Can you please share your roadmap?”

“What are your plans to engineer feature xxx?"

“Great product, but does your vision match ours?”

I've received these questions all the time, from customers, partners, and analysts.

When leading Product Marketing at an open source software vendor, I felt it antithetical to be open and transparent about code, financials and priorities - but not about our actual product roadmaps. So we decided to open-up our product and solution roadmaps for each product. And on reflection, if you're selling enterprise software, it's probably a good idea for you to consider this approach too (whether or not your product is open source).

Why do this? Are you crazy?
There are a number of reasons to consider taking this bold step - a step that many high-tech companies shun as competitively risky - and thus guard their roadmaps with absurd paranoia.

  • Public roadmaps are consistent with openness and your customer community
    I trust the customer/partner community, and they can only trust you if they know your plans. That way they are always involved in your development and you'll be able to best deliver meaningful new features, contributions, and roadmap suggestions.
  • Public roadmaps signal honesty and transparency
    Transparency is key to building trust between partners. A public roadmap helps committers, partners and customers to know you're not pulling any punches with your direction. With transparent roadmaps, your technology partners know what to expect… and have a proactive vehicle to comment on the direction.
  • Public roadmaps are good to build customer trust
    When customers buy into your platform, they’re putting their technology direction on the line. They want to know if you'll be evolving in the direction they want. For them, it’s all about mitigating long-term technology risk. This way, “opening the kimono” and boldly stating direction, is just plain good for the long-term relationship.
  • Public roadmaps show your pride, confidence, vision
    Assuming you're proud of your engineering, and confident in your company, you should show it. Your thought leadership material ought to indicate direction - but put deeds behind words, and commit to technology direction following your higher-level vision.
  • Public roadmaps are good for businessIn sales situations, customers often ask pointed questions about specific (missing) features. And the usual answer “yup, we’re working on supporting it” is always received with skepticism. However, public roadmaps put your money where your mouth is… either it’s on the roadmap, or it’s not. And if the roadmap doesn't reflect mutual direction, work with customers/partners to change the roadmap… with everyone else to see.

Are you nuts? The competition will clobber us!
In reality, your competition is probably dealing with their own internal politics, debates and direction - and may not have time to seriously consider yours. And if they do take your roadmap into account, that generally indicates that they'll be a follower, not a leader.

OK, I get it. But what will Legal say? 
True, your counsel will generally play the safe/conservative card. Their concern generally takes one of two angles: (a) Corporate liability if you somehow don't fulfill on your promises to customers and/or to the market, and (b) risk to near-term revenue by possibly stalling sales... if customers sit back and wait for you to actually deliver on the promised features.

To these, I respond with a bit of marketing pragmatism: First, you should always add some form of legal disclaimer to your roadmaps. Roadmaps are your best, honest intentions - but they're not guarantees... so say so.  And, roadmaps have to do with *direction*, not necessarily with granular specifics - so it's OK to be vague and avoid details that could changes as development runs its course. 

And regarding stalling purchases/revenue, consider this: If a customer is going to delay a purchase to see whether you deliver on a roadmap component, you probably run a greater risk of that customer going to a competitor in the interim.  So I say, try to win them over *now* with your direction, and maintain their allegiance as you build on your roadmap.

Thoughts? In the theme of transparency, I'd love to hear yours !

Other Resources: 

(Note:  A version of this blog originally posted March, 2019 on

Saturday, December 8, 2018

The Virtues of (Personal) Networking

I’ve taken a bit of hiatus from blogging as I’ve settled-into my new gig at WSO2. But I’m back with a career and social observation that applies to everyone. 

This past week – partly by chance, partly by design – I’ve had lunch/coffee with

  • A CEO / Serial entrepreneur looking for marketing guidance on his latest venture
  • A college alum reaching-out for an informational interview
  • A product marketing leader wanting to share professional experiences

It’s been an interesting set of wide-ranging conversations. But taken as a whole, it dawned on me that everyone, no matter what their level or level of discussion, should go out of their way to expand their network and “pay it forward” by sharing experiences, knowledge, and connections.  Never turn down an opportunity to exchange ideas or to meet someone new. 

The LinkedIn era

This is a new career era where potential employment is as much about using your network and knowing someone, as it is about being discovered via blogs, LinkedIn, etc.   

As a hiring manager, rarely does a good resume come in because of a passive job posting. Rather, almost always good candidates are found in the blogosphere, on LinkedIn, or through a referral by a friend / colleague / Tweep.

So as the saying goes, one’s professional value is as much “what you know” as “who you know”. Per the Network Effect, every new contact you make exponentially expands your marketability, source of knowledge, and overall professional value. So the act of expanding your network makes you more discoverable and valuable.

A nod toward WSO2 Principles

The other aspect of my (new-ish) philosophy is reflected in two of WSO2’s six new principles (we will announce them soon) that all of our employees embody. I try to take-them-to-heart every day in the office.... and outside. You should too:  

[Life is a] Journey of Experiences
  • Each person is on a journey of constant growth.
  • We provide everyone opportunity for their best journey.
  • We are humble in accepting feedback and act with integrity.

[We are a product of] Community Contribution
  • We are part of a wider community.
  • We stand on the shoulders of other giants.  
  • Everyone contributes; therefore, everyone can influence.
  • We want to contribute to communities, facilitate external contributions and encourage community participation.  

These two principles speak to me professionally – to see that my career is a journey, and it is my (and our) individual responsibility to make the most of opportunities to learn from anyone and everyone. And the broader tech/business community is valuable to us when we constantly share our experiences amongst friends and colleagues.

As corporate principles, they also speak to me – to appreciate every employee and colleague’s experience, perspective and approach to their job. And to take all feedback (the good and the bad) as a contribution. As part of the open source community, we also have to be humble, but also realize it’s our responsibility to contribute back to the community-at-large.  

Networking is holographic - Our network of experiences, and our contribution to/from our community, is true at work as it is in life.  So meet new people. Struggle against being insular; share information, don’t hide it.

Propel others. In doing so, you’ll propel yourself.


Tuesday, May 1, 2018

4 Warning Signs an Integration Wall is Approaching

The Integration and API Management markets are growing,  expanding in both popularity and use.  Enterprise App integration will surpass $33b by 2020, and other markets like iPaaS and Data Integration are growing at double-digit CAGRs.  Enablers, such as  containers and serverless technologies are only accelerating the move toward increased disaggregation of applications.

All seems rosy. And it mostly is.

But with the explosive growth of APIs and endpoints, traditional centralized tools like ESBs will become unsuitable, and simple low-code snap-together tools won’t scale to address the broader scope.  We’re potentially about to hit an “integration wall” at high speed.

Consider the following four warning signs – some technical, some process – that I find are beginning to plague the integration market:

1. Waterfall Development for integration is hitting a wall. 
Although most code development has shifted to an Agile Development model, the same can’t be said for Integration tools. As the quantity and diversity of endpoints increases, and as Integration projects become more diverse and complex, use of the waterfall model is beginning to slow down integration projects.  And with a future where there will be billions of Integratable endpoints, it’s obvious that an Agile Development model for integration will need to become the norm.

2. Existing tools and programming languages aren’t optimized for Integration-at-scale.
Enterprises that currently use low-code, snap-together, centralized integration technologies (including iPaaS) will not be optimized for orchestrating, integrating, observing and governing the expansion of constantly-changing endpoints. Nor are traditional centralized approaches (think: EDI and older ESBs) prepared to handle increasing endpoint scale or diversity.  Many of these existing tools are well-adapted for Line-of-Business or Citizen Integrators of relatively small-scale implementations but are far from well adapted for more complex integration-at-scale projects.

3. Current programming languages are not optimized for Integration. 
With languages like Java/Spring or JavaScript/Node, developers can engineer flow, but must take responsibility for solving the hard problems of integration. With these languages, developers have to write their own integration logic or use bolt-on frameworks.  Clearly a new programming paradigm will be needed long term.

4. The Exploding Endpoint Problem is very real.
As I referenced above, IT is ill-prepared to address the oncoming wave of service disaggregation, the diverse types of APIs, differing sources of service endpoints, challenges from Big Data, and multiple approaches to serverless IT. The industry is about to hit a scale and diversity wall. To wit,
 • 917 apps in use per enterprise (Netscope, 2016) 
 • 893-1206 average cloud services used per employee (Kleiner Perkins, April 2017)
 • 19,000 APIs as-of January 2018 (Programmable Web, 2018) 

And if you don’t believe those numbers, Matt Eastwood of IDC recently pointed out that the number of containerized services has expanding well beyond where VMs ever were.  Yep, billions of programmable endpoints aren’t kid’s stuff.

Where does this leave us?

A new approach to addressing the future of integrating thousands – or millions – of endpoints could lie in a new programming language, Ballerina.

Ballerina is a simple programming language whose syntax and runtime have been optimized for the hard problems of integration.  Its focus is integration – bringing concepts, ideas and tools of distributed system integration into the language.  Based on the concepts of interactions within sequence diagrams, Ballerina has built-in support for common integration patterns and connectors, including distributed transactions, compensation and circuit breakers. And it supports JSON and XML, making it simple and effective to build robust integration across distributed network endpoints.

So, watch this space for future developments. And in the meantime, beware of the approaching wall.