Archive for the ‘admina’ Category
Thank you for stopping by and reading posts here on Learning By Shipping.
The learning continues, but new posts can now be found on Medium. Please visit http://medium.learningbyshipping.com.
This site will remain archived and supported and occasionally will receive cross-posts.
Thank you for your support,
Nothing is more critical to a software-as-a-service (SaaS) business than pricing strategy. Pricing is the moment of truth for a new product … and doubly so when it is a company’s first product. But far more often than not, I’ve observed new startups leaving “money on the table” when it comes to pricing enterprise products. I’ve seen founders say their product saves hundreds of thousands of dollars — yet their product is priced as if it’s only saving thousands of dollars.
One reason for this is assuming the need to price and program similarly to competitive products. With a potentially disruptive product, however, falling into the trap of pricing like a legacy competitor not only leaves money on the table — but it could fail to surface your differentiation. Said another way, your product is your price and how you price your product reflects value from the buyer perspective as well as what your company believes is valuable. SaaS products also have the advantage that they are priced not just for the service they offer, but for the potential of saving massive capex/opex spent directly by the customer.
From your business perspective, SaaS products have a level of stickiness that would be the envy of the packaged-and on-premise software generation.
Since the uncertainty and social science aspects of pricing can be uncomfortable, especially for technical founders, here is a framework — from the perspective of a product manager — to consider when pricing new SaaS products. The product manager role is critical in SaaS because the ability to fine-tune the monetization of the product is closely tied to its features and implementation. The product needs to be designed with such flexibility in mind when it comes to making features available, prioritizing features, or even just choosing where to spend engineering time.
Just remember that “business isn’t physics”, as Bill Gurley notes in his excellent post on some of the metrics here. Andreessen Horowitz also has a detailed primer on understanding SaaS valuations as great background for pricing discussions. Because pricing is math, there’s a tendency to create the spreadsheet model and assume it will all work. But there’s also a ton of psychology that comes into play: beyond math, pricing involves judgment, vision, and flexibility.
How do you solve an unsolvable problem? Bound it.
In a new business, it’s easy to spend money, but the combination of a new product and the unknown cost of acquiring customers leads to an “unsolvable” problem. One approach is to take lean/iterative methods and apply them to finding the right pricing fit. This post is about a framework to arrive at such early prices, which will change. (This is very different from what happens in an existing company with existing customers, where you really only get one shot at pricing something right).
The business side of SaaS involves a complex array of variables such as customer lifetime value (LTV), customer/subscriber acquisition cost (CAC), average revenue per user (ARPU), cost of goods sold (COGS), and churn; as well as pricing models such as freemium, tiered, and time based. Then, depending on whether you’re targeting consumers or enterprises, there are very different sales models that influence your pricing approach (for example, business products invite complexity, especially when dealing with purchasing managers). Similarly, the product side of SaaS is a complex set of equations related to usage patterns, scenarios, and variable costs of a large number of resources.
The most critical costs are related to customer acquisition and sales/marketing expense — which can appear to erase any potential for profit by traditional accounting measures — so the key to early-stage SaaS businesses is to focus on understanding customer acquisition costs relative to the estimated long term value of a customer. Since we don’t know how much it will cost to acquire a customer yet, we will just have to move forward assuming some budget (along with some allocation for margin in the ultimate price relative to this long term value). This post focuses on the pricing models relative to product and features and assumes a higher level view of customer acquisition costs and long term value.
One way to approach this is to establish upper and lower bounds on pricing:
A lower bound for your pricing
The lower bound represents your costs to serve a customer your product. One common example is the basic costs of spinning up the IaaS/PaaS elements of what you do — creating accounts, allocating minimal resources, other infrastructure, and then subsequent usage.
It might be convenient to think of this lower bound as what you could offer for “free” to some customers. You might make some assumptions about the use of variable resources such as compute, egress, storage, etc. in order to arrive at this lower bound. (Note, since this is a product-centric view these bounds are absent the allocation for fixed and variable costs outside the product/technology, so do not not include opex, S&M, etc.)
It is important to understand this bound across the full breadth of your product. While you might initially view some features as “premium”, you also want to assume that over time capabilities will migrate from advanced to essential and you will fill in new features at the top. I think it is a good exercise to consider the full product as a base case initially.
An upper bound for your pricing
The upper bound represents your costs to serve a “depth” user: in this case, the customer using the parts of your product that drive ongoing costs to scale (for example, this customer is using increasingly more bandwidth, storage, or compute). Now this is where you can look at what you offer relative to your competition, and want to understand if you have scale attributes that are better/worse/same. By knowing this you can begin to separate out variables for your model.
Presumably in developing your product, you created a unique architectural approach relative to existing competitors. Do you scale better for more tenants, use storage more effectively, or maybe your mobile app is more efficient at bandwidth? The importance of knowing your own strengths and weaknesses will inform what variables to use in your pricing.
You can also think of your upper bound as a competitive foil — the stronger you are on some attribute, the more you should use this attribute to differentiate your offering. This might allow you to charge more for capabilities that are just too expensive for your competition.
These are the core attributes for pricing
When you’re pricing a new offering, it is worth understanding where your product is today relative to a core set of potential pricing attributes.
Whether it is Bronze/Silver/Gold, Free/Select/Premium, Trial/Select/Premium, or Individual/Business/Enterprise, the norm for SaaS is to offer a “3xN” matrix of 3 pricing plans and N attributes — as inthese examples. The more mature a SaaS product, the more rows and columns its matrix has. (One SaaS product I researched had five top-level features organized into an array of 27 price points based on combinations of the three to five of the features and number of users.)
A broad range of SaaS products can be considered across the following core service attributes:
If your product lends itself to dividing the features themselves — such as import/export, visualization, view/edit, or connectivity to other products — into good-better-best then differentiating price points here might work. In a freemium model, dividing must-have features among free v. paid users can be a customer-hostile way to differentiate or optimize pricing, so beware.
The reason to hesitate on this dimension is because customers understand that you’re basically just inhibiting access to code that is already there and hence being draconian. Another reason to be cautious with this model is that as usage of the product deepens over time, paid features will tend to get pulled into lower-priced tiers — which means you need to fill in new features/prices with every release or update. As easy as it is to communicate general-use features in pricing tiers, there’s a level of distaste with this approach for many customers.
One of the most common approaches to differentiating a SaaS product designed for business is to separate out the IT-focused features as a pricing attribute. These could be features for security, audit, identity integration, domain names, sharing, control, management, etc. Businesses understand what it is like to both value and pay for these features.
Commonly this approach is used to rectify a product that has become viral within an enterprise, so be careful about how you approach an enterprise with pricing here. Otherwise you might come across as an arsonist-firefighter who is offering to contain the very situation you knowingly created.
Scale in consumption
Another broadly used SaaS pricing attribute is storage consumption (even for products for which storage is not a primary attribute): It’s easy to measure, easy to articulate, and is relatively expensive. The benefit of using storage is that people “get it” to some degree. It also gets cheaper faster than people can consume it (and in most scenarios customers need to be doing something fairly extreme to consume vast amounts of storage). At the same time, the platform companies have been steadily increasing free storage or ultra-low priced storage as a base, no-frills service so simply using storage as a one-dimensional offering might not work. With a new SaaS product, be sure to consider ways to avoid basing costs on storage given challenges.
One novel approach seen recently is using third-party storage and letting the customer establish a paying relationship such that storage is not part of the pricing of your product, since that way you do not serve as a pure pass-through for a visibly priced third-party element of your product. There are many novel attributes in modern software that can be used as consumption variables; one relatively new one is to use depth consumption of APIs/calls as a price tiering structure. (Box, where I’m an advisor, recently announced pricing for Box APIs as an example.) Developer-oriented products work especially well for consumption pricing because developers understand the product architecture and what can drive costs, even if those costs are variable with usage.
Scale in consumers
SaaS products used by small teams, cross-organizations, or that just scale with more members collaborating/sharing/using are almost always priced by number of unique users (and subsequent integration with organization-based directories). Pricing this variable is straightforward and over time you will see distribution of engagement and resource usage that will further let you refine the discrete price points.
Because most products priced this way also want to encourage more users/usage, carefully consider where you put the first step or two. But large-scale customers like this approach because it allows for predictable pricing on a metric they understand: number of employees/users. In general, you can think of this as per-seat pricing but can also apply to device end-points, servers/CPUs, VMs, etc.
Segmenting your customers
Every product is used by different customer segments — whether measured by size of organization, industry segment, geography, or type of individual within an organization. Common pricing tier labels here include “government”, “non-profit”, “academic”, “healthcare”, “small business”, and so on.
As a product matures, you will almost certainly either label or expand your pricing tiers to account for this. Before you jump into this level of differentiation, however, you want to gain more data on usage — are you seeing customers across some set of segments, and are they using the product differently? More importantly, do you see a path to develop differentiation that allows you to target and sustain these segments (or are you just optimizing revenue along these lines)? Some products are designed only for specific segments like education, which allows you to further refine within them: e.g., public, private, post-secondary, etc.
But one customer segment that is almost always special is the engaged technical user. These folks can push a product through an organization when required, or develop custom solutions on your platform that either deliver or enhance the value of your work.
Developers are key in this regard. For any platform-oriented product, it is worth considering how you offer developers the ability to experiment with and use the full product in a development environment at a very low price. One way to accomplish this is to separate out usage-as-development versus usage-as-production, and price accordingly.
* * *
As a new offering with any established competitors, pricing will be the easiest point of attack. And if you are a disruptive product, you want to have the deepest possible understanding of the value you are bringing to the table so you can maximize the initial pricing model. So the most important suggestion for pricing I have here is to wait until the last possible moment to price and announce.
Even for enterprise products, things like round-numbers, 9′s, and discounts all matter. Do keep in mind that discounting will be substantial in enterprise products with direct sales and 50% or more off “list” price is not uncommon (and often required). That’s not an excuse to bloat the price, but it is important for purchasing managers and for empowering your salesforce that you enable a level of customization — and know what variables you are using to do so.
Some say that you can never change or raise your prices once you’re out of the gate. Always keep in mind that once you have customers, price changes or product composition relative to price are never viewed as positive changes, even if you think for some customers you are lowering the price. And when you do change your prices, always offer existing customers time to adapt and grandfather them in (at least). Finally, remember to engineer a product framework that can support pricing flexibility.
Create the model, use the model, but don’t let the model do your thinking. Price carefully!
–Steven Sinofsky (@stevesi)
This post originally appeared on TechCrunch.
In technology product development there is always something new on the horizon—something better, faster, lighter, slicker, or just shinier. These shiny objects—technologies that are not quite products but feel like they could be the future—are the stuff that hot news stories are made of, that people will stop and ask about when they see one, or that cause a halo around a company. Balancing existing products and minding the business while developing wildly new products is always the biggest challenge facing established organizations. It is also a big challenge for each of us when we consider all we have to get done in the near term.
Recently there have been a lot of stories about companies doing “crazy” things while at the same time there are stories about the challenges in the “core” business. Google is famous for having very forward looking projects–internet balloons, driverless cars, connected glasses–while at the same time there is a huge transition going on in mobile computing that might impact the web search business that is so phenomenally successful.
When things are going well for a company, shiny objects are hailed as forward-looking innovations from an industry leader. Impatience dominates as people want to see these products in market sooner. When things are not going well for the company, perception radically shifts to one questioning focus on the “core business”. Impatience dominates as people want to see the company stay more in tuned to the challenges in the near term.
In practice, any organization of size engaged in any business with traction needs to be out there firing on all cylinders with the current business while also innovating radically different ideas. Finding a balance in resource allocation, company organization, and both internal and external communications is always going to be a challenge.
Research on the topic led to the work The Ambidextrous Organization, by Charles A. O’Reilly III and Michael L. Tushman. In this work, the authors researched how companies can innovate while maintaining their existing work. As you can imagine, there’s no simple formula or rule and context matters a great deal. The original paper from 2004 has some great case studies worth a read. One of the key learnings is that organizations can be ambidextrous, even if individuals are not always able to deliver on the current business while executing on a new venture at the same time.
In fact doing both at once is almost impossible—both are full time jobs, both require immense focus and dedication, and in reality there are different skills. From my perspective the real “trick” to being ambidextrous is to realize that an organization as whole (the company) needs efforts across a full spectrum of product development innovations. There’s a need for research labs doing pioneering work in deep technical challenges using their depth knowledge and a science-based approach. There’s a need for product development organizations to push the boundaries on existing technology bases in developing innovative new features. And there’s a need for product development organizations to themselves pioneer new products, line extensions or new lines, using their skills in bringing technology to market.
If you consider that a company is a portfolio of efforts and that different skills are required to make different advances, the notion that companies can lose focus or get distracted by shiny objects does not really make a lot of sense. It is certainly the case that one person can be drawn to be too focused on new things and not leave time for their responsibilities. The more senior a person, all the way up to a technology CEO, the more they wear many hats, context shift, and are generally required to focus on many things as a basic job description.
If you’re an engineer working on your company’s bread and butter there’s probably a time when you’ve been frustrated with the company’s shiny objects. When things are going well, the folks working on those look like they are creating the future. When things are not going well, you might think the company is squandering resources. Realizing that much of those observations are just perception, you can feel fortunate that your company leadership is working hard to be ambidextrous. You can do the same for your own growth and learning. Rather than get frustrated, get learning.
Here are a few things you can do yourself to exercise the creative side of your brain if you’re feeling a bit jealous of those shiny projects while you focus on getting the next money maker out the door:
Use competitive products. Nothing can make you think differently about your own work than to live and breathe your main competitor’s product. While not everyone can do this (if you work on jet engines that is a challenge), but do the very best you can to see your competitor’s products from the perspective of their customers. Products can have different conceptual models or approaches and thinking outside of your own box is the first step in being ambidextrous—because sometimes a breakthrough in your product is simply a recognition that your competitor has a better way to approach things.
Attend conferences outside your core expertise. Go to a conference that is in your domain but stay away from the sessions about your company and products. Much like using competitive products you can learn a great deal by attending a deep technical conference and freeing yourself from your own technologies and products. Don’t just stick to your own domain. You can expand your mind by shifting to another technical silo. If you’re a backend developer then go to a games conference and learn the techniques of storyboarding and animation for a change. If you’re industry has a tradeshow then see if you can explore that, but again shy away from your core expertise and expand your perspective. Of course whenever you attend a conference, you owe it to your team and your company to share the learning in some structured way—blog posts internally, team meetings, email, etc.
Explore on your own. Engineers are famous for their garages, basements, and spare rooms. These are where some of the most amazing innovations in technology were created. Use that space to be systematic in how you explore and learn. Build something. Work your way through an online course or book on a topic you don’t know about. Be multi-disciplinary about how you think about things by pulling in ideas from other fields as you explore. What is so amazing about today’s technology space is just how much can be done creatively in software by a single person.
Write and share. If you have the start of creative ideas, then write them down and share them. The essence of academic research boils down to sharing ideas and so borrow a page from them. Writing will help you to make connections with people who share your passion but will also help you to expand your own perspective on topics. Writing is hard and does not come naturally for everyone, but if you’re trying to think outside the box it is a great tool.
Keep a list. One tool I’ve found helpful is to keep a list of all the “interesting things” outside of my day to day to responsibilities. New products and technologies pop up all the time. A list gives you a tool you see potential trends and patterns from your perspective. Go back to the list routinely and remind yourself to follow up on a “sighting” and check back to see how it is evolving. Maybe you should use one of the above to devote more time to it?
Where do you find the time? First and foremost, all large companies allow for time for professional development. It is a matter of working with your manager to best use that time. After that, how you grow in your career and skillsets is a function of the time you’re willing to put in. The investment in time is one that pays back.
Back in the 1980’s the buzz in the exercise world was cross-training. Companies, like shoes, always have specialists working deeply across the spectrum of current products to crazy new ideas. No company can be totally focused on one place—that’s just not healthy. As an individual you should consider how to cross-train your brain when it comes to your own skills. It doesn’t mean you’ll be expert at everything, but you can think beyond that of a specialist.
Healthy companies have a balance of existing products, new products, and wild/breakthrough ideas yet to be products. It might be that some think a company isn’t focused if it is working on projects that seem far afield, but that often just depends on the context at the time. As an engineer you should consider your own growth and training in a similar way. Even though there is always more work to do than time, you owe it to your shareholders (you!) to exercise your brain by exploring new technologies and approaches, even while deadlines loom.
Feel free to connect on LinkedIn or follow @stevesi on twitter.