Tangible Differentiation for Premium Products

Posted on 2014/03/18 by Leo Reiter

Offering products and/or services at premium prices requires tangible differentiation, at least if your goal is to acquire new customers and grow revenue. This applies equally to technology products as it does to sporting events, for example. Differentiating on nuances alone can win niche business from aficionados and experts, but you need very obvious benefits if you are to convince the mass market to pay you a premium over the competition. The great thing about obvious (tangible) differentiation is that it appeals both to laymen as well as aficionados.

Formula 1 Racing’s Differentiation

If you’re not familiar with Formula 1 racing, I’ll summarize it for you: it’s the pinnacle of motorsports, recognized worldwide, where teams spend hundreds of millions of dollars per year to compete for two championships simultaneously. The cars are closer to fighter jets than to even the most expensive sports cars you see on the street. Sponsors pay tens of millions of dollars per year just to have their livery show up on television. TV rights cost tens of millions of dollars (or more) per year in most markets. The sport boasts classic, expensive names like Ferrari, Mercedes Benz, and Lotus. Celebrities and even royalty flock to races in such exotic locales as Monte Carlo. It’s been said that NASCAR drivers watch Formula 1 religiously on TV, even while preparing for their own races. Simply stated, this is not your average racing series – it’s above all others, and it’s global.

There are 3 types of Formula 1 fans:

Die-hard aficionados, such as the famed Tifosi who follow Ferrari all over the world
Celebrities, politicians, and royalty who may enjoy the racing, but enjoy the glamour and attention even more
Average racing fans from all over the world, many of whom already follow some other form of motorsport (e.g. NASCAR, Indy Car, Australian supercars, DTM, etc.)

Can you guess which one is the most important demographic for the growth of Formula 1 as a business? That’s right, average racing fans. This is no different than any other business – consider the customer demographics for any premium technology brand:

Die-hard enthusiasts and experts who are 100% loyal
“Fan boys” who don’t fully understand the technology, but know it’s “cool” to own it (and want to be seen with it)
Average consumers of average competing products

Quite obviously, the revenue growth is in convincing the third demographic to spend more on the premium product. The first group won’t grow nearly as fast, and the second group is likely to grow with an increased customer base anyway. The average consumer is where the explosive growth lies, whether you are selling smart phones or tickets to a race. There are far more potential customers in that third category than in the first two combined.

Formula 1 tickets for the 2014 British Grand Prix in July are advertised as starting at 85 Euros per person. This is general admission, not seats. Parking, transit, and lodging is of course extra and highly inflated during the race weekend. NASCAR Sprint Cup tickets for this year’s race at Talladega start at $45 for grandstand seats, effectively less than half the price of sitting on the grass for Formula 1. No doubt the racing is completely different – but to average race fans, it’s still racing: loud engines in fast cars screaming by each other. Did I mention loud engines?

This year’s Formula 1 regulations effectively muted the cars. Anyone who’d ever attended a race or seen one on TV could instantly recognize the insanely loud, high pitched whine of engines turning twice as fast as even the fastest sports cars on the street, and producing at least 2-3 times the horsepower. It’s a sound that is unmistakable. Imagine a jet engine, but louder and higher pitched, and much more mechanical sounding. That pretty much describes it. I’d bet 9 out of 10 people who ever attended a Formula 1 race would mention the sound of the engines right away if you asked them about the experience, even though they wore ear protection. No other racing series in the world sounds anywhere close to it – tangible differentiation for sure.

Average race fans won’t necessarily understand (nor care) about down force levels, braking efficiency, DRS, KERS, or any of the myriad of other technical differentiators in Formula 1 vis-à-vis other motorsports. But the sound of the cars is unmistakable. If you are watching a Formula 1 race, you know for sure it’s Formula 1 and not Indy Car, for example, even if you know very little about racing, and even if you close your eyes. That is, until 2014.

For this year, the FIA (Formula One’s governing body) decided it was time to go “green”. The cars are hybrid, and feature powerful small displacement turbocharged engines. Let’s not confuse this with an average Toyota Prius – they still get horrible gas mileage compared to even the largest gas guzzling SUV’s on the street. Fuel flow is restricted, but again, it’s still racing. Estimates say they use 30% less fuel on average than they did last year. This is a good thing, of course, but at a terrible cost. The new engine and exhaust regulations have completely muted the engines. They sound more similar to street cars than proper racing cars. Again, they still sound racier than your average family car, but not nearly as racy as they used to. And worse, to the untrained ear, they don’t sound too different from other racing categories – in fact, they are generally quieter. Quiet and nondescript is certainly not desirable, but the series was betting on drawing more fans by impressing them with the myriad of new technologies in the cars. This is an arrogant position that ignores market realities. The one differentiator that was clear as day is now gone, and judging by the overwhelmingly negative response from existing fans, it’s unlikely to attract new fans at the prices it demands. Think of Formula 1 as the richest, most decadent chocolate cake. This year, the slices are smaller, there’s 30% less butter, and it tastes the same as anything an average grocery store sells in its bakery. But it still demands a premium price, and it’s likely to go up, not down.

Premium Chocolate Cake is not Health Food…

…nor should it ever masquerade as that, especially if it comes at the expense of flavor or texture. It’s not enough that sommeliers can smell the difference in your cake and pay extra for it. You must trigger the equivalent of an out of body experience in the average chocolate cake eater to get them to pay more for your treats. Chocolate cake is really good, whether premium or not, especially if you are not a connoisseur. If you like racing cars and are not an expert in racing car technology, Indy Cars and Formula 1 cars are not that different now, so why would you pay the premium?

The 2014 Australian Grand Prix Aftermath

As you might expect, almost all the outrage after the inaugural race of the 2014 Formula 1 calendar is focused on the muted engine sounds. The Australian Grand Prix organizers are considering legal action for breach of contract, claiming the sport has lost sex appeal. Fans are overwhelmingly disgusted and very vocal about it, all over the media and the blogosphere. Formula 1 supremo Bernie Ecclestone himself is leading an effort to improve the sound. Formula 1 politics are complicated, but just appreciate that this billionaire knows a thing or two about making money with racing cars. It’s unlikely that existing fans will turn away, constructors will start a rival series, or television networks will avoid renewing contracts. But far more dangerous is that new fans will take their money elsewhere, meaning stunted revenue growth and very angry investors. 2-3 years from now, it’s quite likely the FIA will change things up again, but by then the sport may have lost too much momentum to continue demanding a premium in all markets. As a very dedicated fan, I am disgusted, but I won’t leave the sport because I appreciate all the other nuances and differentiators. However, I will have a very hard time convincing others to start following it now that the most tangible differentiation is gone. Put another way, being “cool” doesn’t carry you too far if you stop doing the things that made you cool to begin with.

Let the lessons of the 2014 Formula 1 season so far resonate in your premium product development. If you can’t grow your revenue stream because you can’t convince average consumers to buy it, chances are your investors will take their money elsewhere. Tangible differentiation is very important to acquiring new customers, especially if you demand premium prices.

Posted in Strategy | Leave a comment

Lessons from a Bachelor Party: Valuing Development Teams

Posted on 2014/03/17 by Leo Reiter

Confession: I spent last weekend at a bachelor party, “off the grid”, about 140 miles northeast of Seattle, WA. Ten savages (yours truly among them) left to their own devises, without a care in the world, honoring a very close friend before he descends into the inevitable abyss of domestic life like the rest of us. At almost 40 years old, it’s about time, my friend 😉

As you would expect when 10 savages who happen to be extremely successful in their respective fields (ranging from technology to medicine, and everything in between) party together, there are precious moments of enlightenment here and there – like enjoying a 5 star restaurant quality dinner that my sommelier friend designed and executed, with the finest prime cuts of aged American, Australian, and Japanese Wagyu beef on hand, paired with an amazing 2010 Cabernet that he bottled himself. As an aside, the (not too strict) vegetarian among the group was set to eat even the plates the beef was served on after all was said and done. Choice quote of the night was “I didn’t know butter could taste like beef”. If you’ve never tried Wagyu beef, please make the investment at least once – you won’t regret it. Even at retail, it’s still worth it!

Behavior in the Context of a Team

Perhaps even more memorable than that dinner was a brilliant two hour conversation I had with the guest of honor’s older brother who specializes in child psychology and consults the state of Washington as an expert in the field. We were cooking up collard greens to accompany the steaks later in the evening as we discussed behavior patterns. I maintain that as a leader psychology is perhaps the most important tool at your disposal. If you don’t understand nor care why human beings do the things they do, then choose instead to follow rather than lead. The main takeaway from the conversation was that behavior is important only in the context of relationships. This is two-fold. There is the person actually exhibiting behavior, and there is the person either enabling it or causing it. You cannot consider one without the other. In his (correct) estimation, almost all bad behavior in children can be traced back to parenting, whether malicious or not. Correcting a troubled child is about teaching the parents how to conduct themselves more than it is about anything else.

Not surprisingly, this applies to any other situation, including the “behavior” of a software development team. Of course we are dealing with educated, independent adults in this context rather than children, but the concept is the same. Sustainable “Good behavior” (on-time delivery, accurate implementation, etc.) of developers is directly dependent on team chemistry and team leadership, period.

Do you Have the Best Development Team?

Flashing back to a debate I had about 9 months ago as to whether or not I had the best team, I’ll put it in further context. My answer was of course yes. If there was any issue with team chemistry or execution, I dealt with it in stride, even going as far as replacing resources if necessary. But the question really being asked was if I had an “A” team of talent, meaning the absolute best developers I could find. The answer again was of course yes. And this is where the disconnect started. It’s true there is always better talent out there, no matter how good what you have is. But it really doesn’t matter unless you actually have problems (that you should no doubt correct). Every single one of my developers had passed tough technical scrutiny and was capable of delivering what I was asking of them. Considering that only a small percentage of developers really “get it”, I felt I had the upper 90^th percentile in house. Did I have the upper 99^th across the board? Probably not. But again, it doesn’t matter. Applying Malcolm Gladwell’s take on the inverted “U” curve, trying to achieve 99^th percentile would have either paid diminishing returns or failed outright. I already had the team I wanted, and in fact it was the best team out there. Never mind the risk and effort of finding better talent (you know how difficult it is), never mind the disruption to schedules while onboarding new resources, and never mind the budget strain of upgrading at that stage… it just wasn’t necessary since I already had the best team.

What Really Matters in a Development Team

Here’s what really matters: trust, mutual respect, and accountability. All things being equal, this distinguishes “A” teams from teams that fail. Your responsibility as a leader is to maintain legitimacy (e.g. lead by example), hold your team accountable for its commitments, and ensure that talent is applied correctly to the problems being solved. In an Agile model, this is fairly inherent, and as obvious as the fact that the sky is blue. But to an outsider who is perhaps more accustomed to judging sales professionals, it can seem like a foreign concept. How can more talent not mean a better team? Here’s how: trust and mutual respect take time to establish, and accountability is something that many very talented developers are not comfortable with. To me, a top performer is someone who I can trust, respect, and delivers what he/she commits to. Raw talent is not in that equation, because again, I already recruited the top 90^th percentile. Just as important is that other team members trust, respect and hold the top performer accountable as well. When you look at this through the lens of psychology, what you have is behavior in the context of a healthy relationship, plain and simple.

How do you value a Development team? Setting aside that you’ve already recruited strong talent, if the team members (yourself included) trust, respect, and hold each other accountable, it’s an “A” team. Upgrading individuals won’t necessarily increase production, and in fact may have very detrimental effects. Fixing problems with chemistry is far more important, and is something you should be doing constantly to maintain that “A” team.

Posted in Leadership, Life | Leave a comment

Startups and Grown-ups: 3 Simple Tips to Survive and Thrive !

Posted on 2014/01/20 by Leo Reiter

There’s no reason why you can’t get involved with early-stage startups later in life provided you are willing to put in the effort and temper your expectations. As we grow older, our lives become ever more complicated and our responsibilities expand. Most people choose job security as time goes on, in order to focus on what is really important to them (e.g. family, retirement goals, etc.). Some people choose startups, and a small fraction of us actually prefer early stage ones (handful of people, little or no capital, etc.). If you understand these types of environments they either terrify you or invigorate you (or both). I personally cannot get enough of them – having moved on from a company I co-founded years ago after helping to evolve it into a larger organization, I immediately found myself at home working with a couple of maniacally driven entrepreneurs focused on seriously disruptive technology – this time as an early stage executive rather than a co-founder. But nonetheless, early stage is early stage, and if you’re in it, you know that it’s a whole different ballgame than anything else out there. And it can put serious pressure on your family, livelihood, and health.

There’s no question you had far more time and effort to give when you were younger and unattached to anything other than your work. But you have one critically vital advantage today that you didn’t have 10, 20, or more years ago: Experience. It’s what helps you work smarter, not harder, get things right the first time, and maintain equilibrium.

The one thing you must do in order to succeed is to maximize your productivity at all times. Just as small companies win when they out-smart, out-produce, and out-maneuver their larger competitors, you must do the same at an individual level to win. Most of this is mindset and determination, but I have found 3 key elements that help tremendously.

Control your Blood Sugar Level

As with all creatures, humans are genetically programmed to survive. One of the most fundamental survival instincts is to find food when we need it. Sure, food is abundant today and we don’t have to chase after large game for days to produce it, but even a few minutes of low blood sugar can distract your brain from the task at hand. A good strategy is to maintain steady blood sugar levels throughout the day. This means what food you eat, and when you eat it, really matters. Do it right, and it has the added benefit of keeping your body healthy as well. I’ve personally found that eating high protein meals and avoiding sugars is what works best for me. More generally, eating foods with a lower Glycemic index means your blood sugar levels spike less after meals. Since “what goes up, must come down”, your body doesn’t “crash” as quickly when your blood sugar did not rise too much to begin with. In practical terms, you don’t feel like you’re starving an hour or two after you finish eating when you avoid foods with high GI’s. Your body takes longer to metabolize what you consume, and your blood sugar levels vary far less, letting your brain know that you’re not going to starve and can therefore focus on more evolved tasks. I believe any form of diet can be altered to avoid sugars, including strict vegetarian ones. If you’re pretty open-minded (and don’t think saturated fat is evil in all contexts), take a look at what the Bulletproof Executive has to say. Note: I have no affiliation with this, just find it an interesting resource.

Exercise Every Single Day…

…or at least almost every single day. Everyone knows that regular exercise helps keep your body (and especially your heart) healthy. But what about your mind and spirit? Let’s face it, when you’re doing an early stage startup and balancing family life all at once, there is not much “you” time left. You need to set time aside each day where you are the only thing that matters in the entire universe. This is not selfish – this is a necessity. I find that combining physical exercise with this “me” time works wonders. No matter what discipline you follow, exercise demands focus in order to be effective. Focusing on your movement, balance, and breathing is all about making yourself the center of the universe… for at least 20-30 minutes per day. Which brings me to an important point: avoid choosing fitness programs that demand too much time commitment. This of course varies per individual, but think about fitness disciplines as something you will do for the rest of your life. Is 2 hours at the gym every day for the rest of your life sustainable? For some it may be, but for me it’s not. I’ve found that 30 minutes is the magic number for me – I prefer short, very intense workouts to longer “endurance” ones. Your mileage may vary, but pick whatever makes sense for you – and be honest with yourself. This is not some New Year’s resolution that you will give up on by mid February – it’s a vital element of your health and professional success. Get it right, and you will realize tremendous physical and mental benefit. And don’t forget to account for the “commute” time and effort to and from your exercise facility. Personally, I exercise at home, where there is no such commute, and by extension, no excuse.

Avoid Passive Activity

Just like your muscles atrophy when you don’t use them, so does your brain. Yes, most brain atrophy is related to disease or even aging, but there is increasing research that you can maintain cognitive reasoning through stimulation even as you age. And since cognitive reasoning is critical to your early stage startup success (among many other things), you might as well start stimulating sooner rather than later. I avoid “feeding” my brain information, and instead, ask it to work for it. Try reading more rather than watching television, as a trivial example. One of my all-time favorite sayings is “I’ll sleep when I’m dead.” Of course you need sleep, but when you’re awake, make sure your brain is too. If you look forward to “vegging” out, then early stage startups are not for you. First, you probably won’t have time to. Second, when it comes to your brain, either “use it or lose it”.

Early stage startups are really difficult, especially when you have to balance “grown up” life with your work. Thankfully, following a few simple steps can help make this process easier, and also translate into increased success for your venture (and your life at large).

Posted in Life, Strategy | Leave a comment

Practice Iteration Before Automation!

Posted on 2014/01/08 by Leo Reiter

I strongly believe in automating every single process that’s possible to automate. Humans doing the work of machines is a waste of precious resources. But recently I realized that as with all things, timing is everything. You can’t just set out to build an automated process from the go – to be successful, first you must iterate. When it comes to process, this means documenting and implementing manually from the documentation.

As obvious as this sounds, I’ve lost count of how many times I’ve seen people rush to choosing (and debating) tools before a process is even written down. I’m just as guilty – to professionals, process is often self evident and easy to take for granted.

This is especially true when you are crafting a technical process. Recently, my team developed a way to bootstrap heterogeneous cloud-based supercomputing assets at massive scale. This is typically a prime candidate for “scripting”, given it’s a repetitive programmatic process requiring little or no human intervention. There is very little unique configuration for each of these assets, and many can even be determined by querying the computer hardware itself. Rather than jump right into scripting, we documented the process first (in a “HOWTO” format), then implemented it manually again and again. We proved repeatability – one of the key goals of automation – testing, fixing, tweaking, and polishing as we went along. Finally, we arrived at the correct set of steps to script. Transcribing these steps into a machine-readable format is trivial, but determining and hardening them was not.

What did we learn and achieve? First, we really know what we’re doing, despite the fact the computer will eventually do it for us. We made all the adjustments necessary for every permutation we could think of, and are confident that the automation will “just work”. As a massive added bonus, we documented the process for posterity. No matter how good your automation is, it has limited potential without accurate documentation. In the blink of an eye, “tribal knowledge” can erode or disappear completely, and making future functionality enhancements can easily mean starting from scratch. Equally daunting is troubleshooting future failures without really understanding how the process works.

Could we have arrived at the same result had we jumped right into scripting? Isn’t testing and fixing a script somewhat the same thing as iterating through a manual process? While it can be effective, the additional overhead of building elaborate mechanisms specifically for automation can easily complicate what should be the simple task of verifying a series of steps. And in any case, we still would have had to document the process and its adjustments in order to preserve the knowledge for the long run. The way we did it, we even tested the documentation for accuracy as we went along!

Knowing what to automate goes hand in hand with knowing when to automate. Any time you develop process, especially technical process, it’s best to prove and mature it before you hand it off to the machines to execute. Not only will you end up with higher quality, but in many cases, you will also get there considerably faster.

Posted in Development | Leave a comment

“Agile Development”: the Worst Process Name in History?

Posted on 2013/12/31 by Leo Reiter

What’s in a name? We all love clever names because they tell us all about something without having to ask further questions. Just imagine the software industry’s collective joy at a process that embraces business agility and is named accordingly!

I will argue that it’s the worst name given to a product development process in history. (I will focus mainly on development and not operations, although Agile really helps there too.)

Another way to put it is that it’s terribly misunderstood. The term is misused by both advocates and adversaries. Here are some (paraphrased) quotes that I’ve actually heard or read over the past year:

“We need something much more agile than Agile”…

“What’s so agile about 2 week sprints?”…

“If we can’t make adjustments on the fly, we’re not being agile”…

(names and other specifics withheld to protect the guilty)

In each case, the term is both misunderstood and misused. The first person was responding to having to provide requirements in order to see results from Agile Development. In her mind, she thought developers would just imagine and invent products on their own, and then she would get to see if they passed muster. This person was unfortunately miscast into a technical product management role with very little product experience in her operations-centric career. She was given the responsibility of bringing a product to market, but lacked the experience in both the business and technical side of product development she needed to be successful in that role.

The second person was arguing that Agile Development is too rigid for dynamic organizations to use. Having to plan and assess in 2 week iterations – the horror! Much better would be to just decide on a daily basis what will be delivered, and then realize 6 months down the road that nothing works and nothing meets requirements? Or simply try to react to all conditions in real time rather than set up proactive process to anticipate them and execute? If 1-4 week sprints are too rigid for a product development organization, then the preferred process is called “Chaos”, and it’s probably the most widely used out there – just look at some of the junk emerging (or not even seeing the light of day) from startups today as they take the inevitable ride down to failure. In no way do 2 week sprints mean that you cannot support customers in real-time, they simply mean that you cannot create new functionality without some sane window of time to execute within, and a reasonable process to plan with. If you simply react to each customer request without proper product-level triage (including alignment with business strategy and prior commitments), you are a custom development shop, not a product development shop. Remember, products scale because they meet broad requirements in target markets, not because they solve every esoteric problem every single current customer has. This is why investors generally value product companies higher than services companies, but the truth is if these organizations don’t deliver on expectations, the funding stops. Maintaining product discipline is a critical element to ensure current and future revenue growth.

The third person was questioning why he could not simply shuffle his work during a sprint, based on his interpretation of business requirements. This is a narrow view of what product development actually is. In some ways, it’s a symphony, where the conductor (Product Management and Product Owner) have to keep cadence for the orchestra that agreed to play a specific piece. There are so many moving parts. There is business strategy, current and future customer commitments, resource constraints, support responsibilities, and most importantly, resource pooling to achieve a common goal. A team cannot execute on a single product if individual members decide to change their assignments randomly during iterations. The single most important part of an Agile Development process, in my opinion, is commitment to team. Team members must trust that other members will deliver on their commitments, so that when it’s time to integrate, the product will actually work. The fact integration is often continuous in modern development shops makes this even more critical. Just think of an orchestra playing Mozart’s Die Zauberflöte while a single violin switches to Beethoven’s 9th Symphony. It doesn’t matter that it’s only 1 violin, it still derails the entire piece!

The real agility is in between iterations, where planning and assessment take place. This is where all the stakeholders, not just developers, realize and adjust to business realities of the product they are building. A regular cadence ensures a positive rippling effect throughout an organization, where everyone knows what to expect and prepares accordingly. It’s all about trust – developers trust each other to deliver the units making up the whole, product owners trust developers to build the code, product managers trust product owners to deliver on business requirements and strategy, and the rest of the organization trusts that the product is robust enough to sell and operate. Given that transparent change is possible between iterations, this allows a business to adjust in dynamic climates without having to wait months for “change requests”… but this cannot be done without process at every level.

While I’m being tongue-in-cheek when I say Agile Development is a terrible process name, it’s very important that both critics and supporters understand what it really means. Reading the Agile Manifesto is nice, but process advocates within organizations need to position this in terms that apply to each organization’s unique business challenges personnel make-up.

Posted in Development | Leave a comment

Is Traditional Enterprise Software Making its Last Stand Against Cloud Licensing?

Posted on 2013/12/24 by Leo Reiter

We’ve all seen this “movie” before. An industry transforms, but there are always some players deeply invested in traditional models that refuse to accept it. Think of the transformation of physical media to digital delivery in the music industry as the most recent mass market example.

The arguments against transformation are almost always based on fear mongering – in content and intellectual property-heavy spaces, it’s around piracy. Any time a delivery medium changes, the popular public objection from the laggards always labels the movement as a way to cheat. We saw it in music, and now we’re starting to see it in “Software-as-a-Service.”

Let’s set the record very straight: consumers are indeed willing to pay for worthwhile content and intellectual property regardless of delivery medium. Yes there is piracy, but this exists no matter how you deliver it. Copying cassettes and compact discs, for example, was trivial – perhaps not as trivial as copying MP3 files, but certainly not something people shied away from. When I was a kid in the 1980’s, trading pirated software on floppy disk was about as widespread as trading baseball cards. And that was before even “bulletin boards” became popular!

If anything, new delivery mediums prove that consumers and businesses are willing to spend more, over time, for content and intellectual property. In many cases, these new paradigms make the point of sale much easier and convenient for the consumer. They no longer have to go to the store to buy music, which means getting dressed, traveling, waiting in line, etc. Now they can just purchase instantly from their mobile device, using a preauthorized payment method. This type of convenience fuels massive expansion of revenue streams. Piracy indeed still exists, but it’s just the cost of doing (more profitable) business.

In the software industry, it’s clear consumers are quite comfortable with pay-per-use models. This is the favorite model of cloud providers – it’s easy for the consumer, while expanding profit margins. Most cloud providers earn a multiple of what they would if they sold perpetual licenses, since over time, consumers and Enterprises actually pay a premium for Software-as-a-Service! However, as businesses and Enterprises cozy up to cloud licensing, it should come as no surprise that certain vendors are resisting, just as the music industry did when consumers moved to digital media.

What really drives the objection is resistance to change, not the fear of piracy. Vendors understand very well that they can profit greatly from the transformation, even with increased competition and perhaps increased potential for piracy. But they also understand positioning to take advantage of this requires an investment – in many cases, a significant one. In our short-sighted quarter-to-quarter business world, we often see businesses sacrifice long term viability for (perceived) immediate returns.

We all understand adaptation is the key to survival, in every aspect of life and business. It’s a tough sell to a Board of Directors however, especially if executives lack the vision to see (and clearly articulate) the light at the end of the tunnel. This is exactly why companies that don’t adapt eventually fade or die, and new players emerge to take their place. Sometimes this process takes years, or even decades, but it happens all the time.

In the Enterprise Software world, there is an established “status quo” for how software is monetized. There are compensation models for salespeople and channel partners. There are also technical challenges due to years of coding for perpetual licensing. Worst of all, there is even a comfort level that comes with locking customers in thanks to significant investment rather than competing on merit with new offerings. Some vendors have dug in and refuse to offer pay-per-use licensing now and in the future, trusting instead that their users will continue to bend over backwards to pay them, regardless of emerging competition. Some at least offer subscription or time-based licensing, but this is only a variation of existing models and is not really cloud licensing. Cloud usage is billed by the hour (or minute), not by the week, month, or year.

On the consumption side, the users (and their providers) will eventually dictate how software is licensed, just like they did in the music industry. They will clearly demand pay-per-use licensing, and that their cloud service provider simply embeds the cost in a single bill. The software vendors who dug in will simply be replaced by other vendors or even open source providers. “Node locked” and even time-based licenses will become a thing of the past. Complex compliance models that some vendors offer today as a stop gap will also fade. Look no further than the historic decline in sales of traditional PC’s in favor of “cloud receiver” devices like tablets and smartphones as evidence of how individuals and businesses want to consume content and software.

The market has spoken, loud and clear, and it wants cloud licensing for software. Are some vendors making their last stand against it?

Posted in Cloud | Leave a comment

Why Aspirations Trump Skills

Posted on 2013/12/20 by Leo Reiter

I’ve given a lot of thought lately to what I consider to be a key pillar of leadership: matching skills with responsibilities. As obvious as this sounds, I can’t tell you how many times I’ve seen leadership teams miscast talent for various jobs and then pay dearly in lost production as a result.

But what about aspirations? If we truly believe in and encourage people to evolve and grow as individuals, shouldn’t this matter more than the skills they possess right now? I feel this is especially important with top producers.

Think of a quarterback (leader) throwing a football to a star wide receiver (top producer) who is running in full stride. Does he throw the ball where the receiver is at the moment he releases, or does he throw it where the receiver will be at the moment the ball arrives? So why not cast team members into roles they will enjoy growing into rather than only contribute to with existing skills? After all, skills can always be developed, right?

In my opinion, there’s no better stimulation for learning than to be cast into a role doing what you love. It’s a minor investment a business can make to ensure its future success – pay a little in immediate productivity to gain tremendous upside once the skills catch up. Contract work can always fill the gap for the mundane static jobs that still need to be done.

Obviously, there are limits to everything. Just like an average height person probably can’t play professional basketball at a high level, some personalities may not excel in certain future roles. A seasoned leader who really pays attention should be able to mentor team members along these lines however.

What do you think? As a leader, how much time and effort do you invest in ensuring your team members’ roles are aligned with their skills and aspirations? Are you willing to invest in future development while you wait for skills to mature?

Posted in Leadership | Leave a comment

Problems and Solutions

Posted on 2013/12/12 by Leo Reiter

Do you know the difference between problems and solutions? Sounds silly, right? You’d be surprised.

Recently I’ve been advising a friend on a cloud computing service he wants to offer, and realized I’m starting to think more and more like an investor without technical domain expertise. When I went back and read what I was asking him, I remembered a time not too long ago when I hated hearing the same thing from investors I was pitching to. I’ve been in cloud computing for over a decade, so you can imagine my own surprise when something so obvious as a service offering became a challenge to think of in market terms. I even had the audacity of asking my friend why someone would want to spend on cloud computing at all for the use case he was articulating. Remember, I make a living from cloud computing. Honestly it was not tongue in cheek – I was simply trying to help him reach the problem statement.

There are problems and solutions. Solutions exist only to solve problems – that is, solutions anyone is willing to pay for. And the single most important quality of any type of product/service offering is that others are willing to pay for it. So why is this dead simple concept often lost when we are dreaming up what we think is “the next big thing”?

You see, I am a solution-oriented thinker, and I would argue most other technical-minded folks are as well. If I’m not thinking of a solution, then I’m not really thinking at all, it seems. What I’ve come to learn is that solutions without problems are incredibly dangerous things, especially when you fuel them with the passion of the technical entrepreneurial spirit that burns hot in some of us. When we act on this, we waste valuable time and resources, and sometimes do irreparable damage to our finances, reputation, family, and even health. This is exactly why good investors don’t pour money into solutions without problems. So the most important question to answer with any offering you can think of is: what problem am I solving?

I think there’s a dead simple test for whether you are articulating a problem or a solution. If you ask yourself what problem you are solving, and your answer is in fact the solution, then you are not articulating the problem. Problems describe pain points and some compelling event to address them. For example, building a better mousetrap is useless if you can’t find anyone who actually wants to buy a mousetrap. And why would anyone need a mousetrap? Well, to trap mice! Why do they need to trap mice? The pain point is fear, and the compelling event is they have mice right now. So, they are in pain right now and they want to solve the problem. Simple, right? The fact that your better mousetrap is more expensive than the product alternative is of secondary importance, although you will eventually need to convince them to spend more on it. So again, attack the pain point – it traps more mice, faster. No one cares if it’s made out of titanium or if it uses 10% less cheese. If you don’t attack the pain point, the superior qualities of the better mousetrap are irrelevant. If you are building a new product or service for a customer who will articulate it exactly as you offer it, then you are either solving an incredibly niche problem, or you are just offering a “me too” solution that the market is already well familiar with. Neither of these is worth investing time and money in, unless someone is paying you for custom work.

Some might argue that we’d have way fewer new product/service ideas if people actually took the time to address problems rather than solutions. I will argue that we have too many new product/service ideas, most with little or no value. Just look at how many start-ups fail, no matter how great their products and their teams are. So maybe it’s time we solve more problems rather than create more solutions.

Posted in Strategy | Leave a comment

Welcome!

Posted on 2011/06/20 by Leo Reiter

With my first post I’d like to just say “Welcome”, and thanks for visiting. After a long break from social media I decided it was time to jump back in, so you’ll be seeing me more on Twitter and LinkedIn. I’m not a Facebook fan and stopped using it after my account was hacked numerous times, so you won’t find me there.

In case you’re wondering, the photo in the header is one I shot in Alaska in May of 2011, from this beautiful place called Potter Marsh.

I hope you come back soon!

Posted in Uncategorized | Leave a comment

Leo Reiter, Unfiltered