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 goals and actions for marketing - for individuals, for teams, and for organizations. My approach is to first ask about what the desired *outcomes* are, and then analyze and break-down the stages of the marketing loop.  

I use a “loop” (and not funnel) because when marketing is done properly, it’s not a unidirectional funnel 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 roughly 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 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 wso2.com)

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.

Thursday, March 15, 2018

My Next Big Thing


Skating to where the puck is going to be

Some of you have noticed my professional interest has shifted. This week I joined WSO2 to help them achieve their next stage of growth.

I am thrilled about this move because the ever-increasing popularity of cloud services and cloud sprawl is triggering the need to integrate those exploding quantity of endpoints – APIs services, events, and data streams.  This is an important technology market, helping companies harness the power of the cloud to generate real business value. It's where the industry is headed.

For me, the opportunity to develop and shape new technology categories for integration, API management, identity and services analytics was too exciting to pass-up.  And WSO2 has a number of unique advantages that I found compelling – ranging from their suite of technologies to their open-source model (and culture) to.... well, stay tuned for a big announcement in the near future.

To be sure, there are already a number of industry players in the API and Integration markets. Most are either pursuing relatively straightforward SaaS integrations around a “hub” (think: SalesForce, WorkDay, Netsuite, Oracle) or building simplified “Citizen Integrator” templated approaches to Integration (think: iPaaS).

And if you somehow haven’t been reading about Containers, Serverless Architectures, IPaaS and others, you should know that the exponential trend toward more, smaller, cloud services is already upon us. Leveraging these technology resources will enable (if not accelerate) the trend away from large monolithic apps (and SaaS apps) toward more granular – and more flexible – services and APIs. And businesses that move in this direction will find themselves with a more agile IT that can respond/adapt to needs more quickly.

Continue to watch this space for tips and observations on WSO2, as well as about the API Integration space overall.