SaaS: Marketing Afterthoughts
I really enjoy working with entrepreneurs – helping them flesh out their ideas and making them successful. But too often I have to ask them – “What is going to make someone look at your product? How will they find it?”
My theory: For SaaS products, marketing should not be an afterthought. Marketing is not a bolt-on for successful companies – it is part of their DNA.
Recently I’ve been working to enhance Scio’s assessment consulting for SaaS products. I’ve been going over past work with clients, proposals, document templates – all the chaff that builds up when you have a consulting practice. We’ve been gradually moving agile concepts deeper into our business practices and it was high time our consulting practice caught up. Sooner or later the shoemaker’s children should get shoes.
One of the great things about agile is it forces you to rethink your documentation and planning to make it more flexible, central, open and – just enough to meet the need. For consulting, it raises collaboration, customer ownership and lowers the image of the “pontificating consultant. ” And in that process of “rethinking” I realized we really hadn’t integrated marketing assessments into the process in the way we should. We certainly included assessments of marketing plans – but we didn’t clearly point out that marketing needs to be integrated into the product from the start.
For SaaS products there are several major market decisions that need to be made during the design process. They related to the product’s position in the market and how the product will be sold. Think of it this way – we say in journalism a good article needs to identify the “Who, What, When, Why and How.” The same is true in marketing. We need to identify:
- Who is going to buy and/or want (they are not always the same individual) the product? There is likely to be more than one “who” involved. In agile terms we call this the “persona.”
- What are they doing? When? Why? These are the contextual stories that tell us what is driving a prospective buyer or user to the product. For agilists – these are the epics – the larger stories that give context and meaning to the product and tell us what is happening around the user that makes them want to use it.
- How is a bit more complicated – it can be considered in terms of “how” a buyer or user finds the service or the product itself can be the enabling agent that provides the “how” a user does what they are trying to accomplish. In agile terms this is realized in user stories but for our purposes that is going deeper than we need. We can stop at the product or intermediary that gets us to the product being the answer to the how question.
That last point begins to bring up the main issue behind this discussion. SaaS applications are not in corporate data center silos. They are on the network we call the Internet. There are three primary things we do on the web: Communicate, seek information, and use services. A premise-based application can provide a limited amount of information from what is available to it within the boundaries of the premise. It can allow communication locally. It can provide services based on its logic and the resources available locally. Getting outside the boundaries means negotiating permissions and controls that are usually outside the application domain – so they don’t exist unless they are very specially configured.
Moving to SaaS suddenly opens up a wealth of opportunities. I came across an article about the basic hub and spoke decision just the other day from Geva Perry. He covers it in a lot more depth than I want to give it here – so I recommend you take a minute and read it if you are considering a SaaS product (or maybe wondering why yours isn’t bringing in the money you expected). The basic gist of it is this – you don’t want your application to be an island in the Internet. It should be a hub, a spoke or both but designing it as an island – as though it was still in that corporate data center – means leaving a lot of potential on the table.
Take Sales: Enabling the channel to add value to your offering is something we have always considered a standard approach in premise-based products. How often is it leveraged in SaaS applications? The leaders – Salesforce, Amazon, Google, Zoho, LinkedIn – have all added some sort of partner program that allows other companies to build applications that add value to their products. The channel could also be an information resource that is focused on your market or a business consultancy or ….But frankly, it isn’t considered enough.
In the case of a product like Salesforce – companies can build their applications using Force.com and sell them through the AppExchange. They can also use the Salesforce API and develop their application externally. They can build their application to expand Salesforce functionality – or not. Each one of these opportunities represents a different potential revenue stream to Salesforce that their sales team isn’t selling directly, that brings in money, and possibly brings more subscribers to their core application.
I’ve worked on a career application that used a strategy of leveraging university job counseling and alumni members as the starting point for new subscribers. They received a subscription as a part of the service or their alumni membership which could be converted to a personal subscription at any time. What better time to target prospects for career management than in their last years in college or when the are just joining the workforce? All that was necessary for the schools was to provide customization tools to allow university administrators to embed the service in their websites.
Each one of these cases exposes a basic idea – that the marketing of these products does not have to rely entirely on external media. It can leverage communities, value chains, social networking, marketplaces – a wealth of opportunities by building them in and integrating them into the core application.
Of course, the reality is everyone has limitations. You can’t build everything you would like to have in your service on day one. Time and cost are the limiting factors in most cases. But even with unlimited amounts of each – a successful launch means limiting your application to the amount of complexity you can reasonably test before you let the product “go into the wild” – the final test of customer-facing performance. Taking this into account, you will need to prioritize and set some parts of the application for a later version. If you develop using modern patterns, automated testing and agile techniques – your development team will be coding knowing what is “yet to come” and where the hooks need to be available to make it easier when that time comes.
But it can be done. Don’t make your marketing plan an afterthought or, come to think of it, your product may end up that way itself…
Marketing is the engine which drives most businesses – certainly those beyond beta; and increasingly the ‘brain’ is the database, as the repository of intelligence gleaned across all customer and prospect interactions. To efficiently leverage these insights across the organization, and be able to respond to compressed lifecycles and fast-changing markets in a nimble fashion, the systems infrastructure has to integrate marketing I/O. As we move into a 3.0 world, ’sales’ will become a more porous function, with Marketing and PR playing broader roles in facilitating engagement and ultimately generating revenue.