Commitments Are The Engine of Performance

‘Objectives and Key Results” (OKR) is a popular management tool. OKRs are a way to disseminate goals throughout the company and ensure that everyone understands their role and responsibilities.  We take the top-level corporate goal, divide it up into a series of objectives that cascade throughout the company in a manner that will add up to achieving the goal.  Each objective has key results that are measurable, so we can determine progress toward achieving the corporate goal.  

The process makes me think about the whole topic of commitments. Commitments are the engine of performance and execution.  Nearly everything we do requires individuals and teams to work together in a coordinated way, and to collaborate across functional areas of the company.  Great execution happens when each team member can rely upon their teammates to deliver their commitments.

Real commitments have a special language all to themselves. A well formed commitment requires an agreement to do something by a certain date – “I will do this by then.”  It must include the time for completion, or else it is just an intention – “I will do this…”  People are usually truthful, and we often can rely on their good intentions, but without a timeframe, or a ‘by when,’ we don’t have a commitment. 

There is a formal language of commitment, and it is something we need to practice and perfect.  In the language of commitment, one party asks for the commitment - “will you do this by then?” The other party can answer in only four ways:

• “yes, I will do this by then”

• “no, I will not do this by then, but I can commit to do it by another time”

• “I can commit to do something else by then”

• “no, I will not do this”

The distinction between commitments and intentions surfaces all the time in meetings and business interactions.  How many times have you participated in a meeting where you asked somebody to do something, and you received a positive response without a date-certain (in other words an intention), only to be disappointed later when whatever you asked for did not materialize?  All the time - right?  Unless there is an explicit timeframe in the response, a mismatch of your expectations and the other person’s intention for delivery is bound to happen.  You think it is immediate, but the other person intends to do it whenever they can get around to it.  A proper commitment is a contract between the parties.  It is clear, actionable, and measurable.

We expect people to be accountable for their commitments, and increasing the pace of performance is dependent upon being able to anticipate achievement of commitments.  For example, if we have a commitment for a feature to be available on a certain date, then we can start to gear up marketing and sales for the new feature in advance of that date so that when the feature ships, we are already moving forward.  Like a receiver sprinting forward anticipating a pass, or a player skating to where the puck will be, if we can anticipate then we can drive faster and harder toward the goal.  The alternative, if we cannot rely upon a commitment, is to hold off until we really, really see the result before we start the machinery to move forward.  If the whole machine is waiting to see if a commitment was real, then performance slows to a crawl.  

Making a commitment requires integrity, intention and truth.  The person making the commitment has to mean it and believe they will achieve the result as promised.  The person asking for the commitment has to trust the person making the commitment, and trust is earned by demonstrating integrity, intention and truth. Integrity requires that we mean what we say - be clear and precise in your commitment.  We also have to fully intend to do what we say. Lastly, truth is the bedrock of committing honestly - no hidden agendas.  Truth also requires honesty about capability and capacity to perform the commitment.  Don’t commit to something unless you believe you can truly do it.

If you are making a commitment, make sure you have integrity, intention, and truth, and expect to be accountable for your commitment.  If your success is dependent upon commitments made by others, make sure you have trust and you are really getting a commitment and not just an intention. Performance and execution depends upon driving true commitments from each other, and everyone being accountable for the commitments we make. When we do this well, we create an unstoppable machine!

True Time To Value

When you buy a cool new gadget, you can’t wait to bring it home and start using it. We all want instant gratification.  Business software buyers are no different.  Once they decide to buy, they want to see results ASAP.

The concept of time to value describes how long it takes for a technology buyer to actually get value from their purchase.  In the enterprise software world, it typically describes the lag from signing the purchase order until the initial launch of the new system. This is a pretty short-sighted view. Think about the broader customer journey, the clock really starts ticking during the early stages of the sales cycle – once a company decides they need to buy a new platform, and it extends beyond initial launch until the system is truly in production and delivering the benefits that spurred the purchase in the first place.

The typical view of a single measure for time to value is just too macro. There are multiple points along the journey where customers receive value and each one should be measured and celebrated. I recall a semi-fast-food restaurant where each step of the way was time-stamped and the staff was quota-driven for efficiency.  The clock started when you checked in with the hostess, and progress was measured from being seated, taking the order, delivering food, delivering the check, and completing the payment. If you wanted an efficient dining experience, it definitely fit the bill. The point is that this restaurant divided the value journey into micro steps and focused on each element of the experience.

There are similar micro steps in enterprise software deployment. Each step is an opportunity to measure and influence time to value, and drive efficiency into the process.  Remember, it is human nature to want instant gratification, so consider every delay as a disappointment. The faster a customer gets through all of the steps from the decision to buy, to ultimate production, the happier they will be.

Returning to the idea of expanding the definition of time to value, a typical approach is to measure only the implementation time from contract signing to initial launch. This is a vendor centric view, rather than a customer-centric view.  It drives implementation teams to focus on their own stats instead of the customer’s view of success.  Customers have a problem to solve, and in an enterprise setting, that usually involves deploying a platform for a range of constituents and departments.  Simply making the system work does not mean the problem has been solved or all of the potential users are satisfied.

Real customer value will not occur until there is a broad launch and the customer sees engagement and repeat usage of their new platform. “If a tree falls in the forest and nobody hears it, did it make a sound” is an apt analogy.  If we stand up a new system and only the project team is using it, did we really launch anything?  Did the customer get any value?  Should we expect them to be happy and renew?  The answers to these questions seem obvious. Engagement and usage are the measures of success, not completion of tasks and delivery of features.  Therefore, we need to expand the concept of time to value beyond simple implementation, and consider the entire journey from determining need to full deployment and broad engagement.

Command and Control or Collaborate

A few years ago, I had the opportunity to attend a management training program at West Point (thank you Edison Partners).  I always thought the Army was a command and control environment where the command hierarchy made every decision and the soldiers just followed orders.  I was surprised to learn that the management principles they taught were quite different.  Instead of micro-management, they taught a version of Objectives and Key Results (OKRs).  The generals determine the battle strategy and big goals - “we need to take that ridge…” The goals and strategy are communicated down the line, but the lower ranking officers and service people are given a surprising level of autonomy to decide ‘how’ to achieve the objectives. I think of it as leveraging the brain power and creativity of everyone, instead of forcing the narrow top-down ideas of a few and stifling initiative.

I also had the opportunity to hear David Marquet speak a few years ago (also, thank you Edison Partners).  David is a retired navy submarine captain who broke a lot of Navy norms and created a management model that led to extraordinary success.  His book ‘Turn the Ship Around’ had a profound impact on me and changed everything about my leadership style.  It is probably my favorite business book, and I have purchased numerous copies and given them to aspiring, as well as experienced leaders. I highly recommend reading it.  A key learning from the book aligns with what I saw at West Point, but goes further toward empowerment and collaboration as opposed to command and control.

We each have to develop our leadership style and decide if we are going to try to lead by being the ‘smartest person in the room,’ or as I refer to them ‘the spitter,’ or are we going to lead by fostering collaboration and leveraging collective brainpower.  The more autonomy we introduce into ‘how’ our team will achieve its objectives, the more freedom we provide for people to be creative, and the more they may surprise us with their brilliance.  I am a believer that just because someone has positional authority, they do not suddenly have a monopoly on knowledge, intelligence, or creativity.  The old saying ‘two heads are better than one’ is true, but think about how much better a collaborative organization can become.  When we do this well, we create an unstoppable machine!

Leaders have a clear role to play, and companies are generally not democracies.  Somebody is in charge, and the buck does stop somewhere.  The question is where on the continuum from command and control to anarchy will your leadership style land.  Delegating decision making authority can be scary, and requires confidence and trust that decisions will be made with full understanding of the alternatives and the consequences.  This level of understanding comes with experience, and trust is earned by demonstrating aptitude and competence.  Leaders cannot simply abdicate all responsibility for decisions, but they can open a space for their teams to grow and demonstrate their ability to take on greater responsibility.

Bold Innovation

I have been thinking a lot about innovation strategies.  I am reminded of two Albert Einstein quotes that seem appropriate:

"The same thinking that has led you to where you are is not going to lead you to where you want to go."

"Creativity is intelligence having fun."

The first quote has always been a favorite of mine.  I have usually relied upon it when people ask for career advice - if you want to advance your career, you have to go beyond what got you to this point.  However, when thinking about our innovation challenges, it really drives home the point that we can’t just think about small incremental improvements or product tweaks if we want to make dramatic changes in our business trajectory.  That would be relying on what got us here to define the innovation for what is next.  This is not to say we have to completely reinvent and start over - to use another quote, “Those who don't know history are doomed to repeat it.” (Edmund Burke).  I think about the innovation challenge as requiring us to be willing to break with the way things were done in the past, and focus on how they will - or could - operate in the future.  Instead of just improving how our customers do what they are doing today, think about how to lead them to a better way to achieve their goals.. “Play it safe and you will always end up with mediocrity” (Simon Sinek).  Taking bold actions can sometimes lead to failure, and sometimes lead to greatness.  It rarely leads to mediocrity.

Innovation requires creativity, experimentation, and a degree of risk taking.  It requires us to take bold steps, and maybe to tolerate some missteps. To be the  dominant force in our market, playing it safe is not a long-term strategy for success.  One of the guiding principles I have followed for years is “always question the status quo.”   Every time somebody says something like “that is the way it’s always done” or “this is how everybody does it,” I immediately question the premise.  Like a little child that just keeps asking ‘why,’ I want to know the root reason for the status quo, and usually that leads to an opportunity for innovation and change.  

At the turn of the 20th century, most transportation was by horse and carriage.  A few innovators created automobiles (or horseless carriages as they were originally called).  The first few cars were pretty inferior to the carriages, but early adopters shaped the industry and cars quickly displaced carriages.  Focusing our innovation on the ‘way things have always been done’ feels to me like focusing on making a better and better carriage.  If we want to innovate effectively, we have to move our industry and deliver different and better solutions. Let’s not become the best carriage maker in a time when the market is moving to autos.

That takes me to the second Einstein quote ‘Creativity is intelligence having fun.’  Every company has smart people with creative minds.  You may need to listen for them and strive to find them in your organization.  They may be hiding under the proverbial ‘rock’ of their current role.  Innovation will be fundamentally driven by creativity, find the creative souls and start having fun creating the next big thing.  Making a dent in our universe (Steve Jobs) is not going to be easy, so make the hard work fun. 

Communication and Collaboration = Customer Success

In an earlier post, I wrote about the customer success doughnut hole. It is the moment on the customer journey when everything is in flux — the vendor thinks implementation is complete and is passing the ball from the implementation team to the support teams, and the customer is transitioning from implementation to operations. It is a pivotal moment that will set the course of the relationship, but it is often the moment when teams drop the ball.

To close the customer success ‘doughnut hole,’ start with an effective handoff from the Sales team to the Services organization. There has to be a clear understanding of what was sold and what was bought. The project kickoff with the customer needs to include pre- and post-sale team members, and it is a moment to make it crystal clear what will occur during implementation. This a time when the customer is excited about the purchase and eager to get going, so the objective is not to throw cold water on their enthusiasm, but it is important to have a clear discussion about what will happen during implementation and where there may be pitfalls along the way.

I am an advocate of insisting on the involvement of the senior buyer in the early phases and establishing a routine reporting mechanism to assess project progress and satisfaction every week. Most importantly, the vendor must establish an ongoing channel of communication with the senior buyer to share weekly assessments and to continually inform and alert the senior buyer to successes and challenges. Too often, the senior buyer steps away from implementation and their only source of news is the customer’s implementation team. The vendor team and the product are always positioned as the reason for any failure, and the relationship with the customer can go south quickly if there is not a channel for discussion and resolution with the original senior buyer. Maintaining a routine channel of communication with all of the stakeholders for good and bad news goes a long way to avoiding disaster..

During the implementation phase, it is also critical to foster solid lines of communication among the vendor’s Services teams. Collaboration across the Implementation, Success, and Support teams to align everyones understanding of the customer challenges and decisions is imperative. Post implementation teams may feel that their involvement need not start until later in the project, but in fact, the more they are aware and involved from the start and throughout implementation, the more prepared they are to smooth the customer’s path to operational success.

Collaboration requires brutal honesty and fact-based candor.  Each team has to check their egos and defensive nature at the door.  You need to build a mutual understanding that the goal is success, not assignment of blame. For each customer implementation, establish a routine process of after-action assessment to highlight where each journey went well, or went awry and could have been improved.  The services and sales teams needs to agree on process changes that will avoid bad situations from occurring in the future.  A valuable tool is a journey map to identify all of the potential forks in the road that will either lead to success or failure.  A journey map can help to build a roadmap to success and an early warning system for future issues.  As a customer transitions from sales to implementation, carefully follow the roadmap and be vigilant to identify and address deviations at every step of the journey - it will pay dividends.  Remember, the customer is implementing your system for the first and possibly only time in their career, while your team does it every day. You are the experts and your job is to guide them to success and away from making decisions that lead to failure. Your roadmap can predict where each fork in the road leads, and you know how to get to success.

If You Can’t Make It – Don’t Try To Fake It

Many software companies pursue acquisitions to advance their products.  All too often, the solution to integrating acquired products is to do a little UI work (lipstick on the pig), and some single-sign-on magic, and call it good to go.  In other words, fake it instead of actually creating the product that was imagined.  Nobody wants to acknowledge that sooner or later the tech from the company just acquired will need to be completely rebuilt in order to make the overall platform consistent and usable.  The leadership, the board, and the investors just made a buy versus build decision, and they landed on ‘buy,’ but now you have to build after all.  Not an easy discussion to have, but all too often, it is the right one.

A huge component of creating a product is defining the capability set and battle testing the product/market fit in the competitive market with real customers.  The product you just bought has presumably already covered this ground.  It is a comprehensive ‘spec’ for what you need, but often it was not built to be a natural fit in your existing platform.  The right, hard discussion is to decide if slapping the products together with some lipstick will deliver the best competitive solution, or will it open the door to a competitor that builds the right product from the start.

This product conversation should be a part of the diligence process.  It needs to factor into the buy versus build equation, and all of the internal constituents need to have an honest conversation about the potential timing and need to rebuild the acquired tech.  The team has to understand the long-term strategy and the path to success.  Too often, the business metrics and financials of the target drive the acquisition discussion, and the tech evaluation is done in a silo that only considers the quality of the tech being acquired, and not the reality of what it will take to create the ideal combined product.  In tech company after tech company, if you look back a few years after they acquired a product, you will find that they ultimately rebuilt the product.  Rarely was that the plan going in, but maybe it should have been.

The problem is that too much energy and angst goes into trying to make it work before some bold soul declares it is time to rebuild.  The market and reputational damage of having an inferior product in the market for too long is done, and now future success hinges on successfully building Version 2. 

This is not an argument to avoid M&A.  A good deal can bring clients and expertise and market penetration and a host of other advantages.  Even the existing acquired product may be highly valuable as a bridge to gain market share while you create V2.0 as long as that is the understanding and strategy at the onset.  However, if nobody is willing to talk about the elephant in the room that the tech may need to be rebuilt, then there is a pretty good chance the shiny new acquisition is headed for product trouble in the future. It is important to have the discussion and set the strategy up front, and factor it into the buy versus build decision.

Keep Your Customer Out Of The Doughnut Hole

One of my favorite doughnut shop proverbs is “as you go through life brother, whatever be your goal, keep your eye on the doughnut and not on the hole.” However for enterprise SaaS tech companies, I beg to differ (a little).

For complex SaaS offerings, one of the root causes of customer angst is often what I refer to as the ‘doughnut hole’ in the customer journey. This is the step on the post-sale path where the vendor wants to declare that the system is implemented, but the customer may not have quite launched all of the processes and features they imagined when they made their purchase decision. It is also the time when the customer team may not be quite stable enough to be self-sufficient. From the vendor’s perspective, this point in the journey is often when the relationship is handed off from the implementation team to the customer success team and the customer support team. On the customer side, they frequently have team members coming and going as the implementation winds down. All of the new people show up with new requirements and lots of questions about past decisions. Unfortunately, the new people are joining right when all of the vendor resources are also in flux, and the launch can fall into the doughnut hole.

The transition from implementation to operation is like a child learning to ride a bike.  Implementation is when the bike has training wheels and it is hard to fall off. Once the implementation phase is “over,” it is like taking the training wheels off and letting go to send the customer peddling on their own. Some children instantly get it and take off, while others fall and want to put back the training wheels, or quit and never ride again. Similarly, some customers “get it” and are immediately self-sufficient, while others panic and become dissatisfied.  The transition from implementation to operation is a very shaky and stressful time in the customer journey, and it is certainly not a time to let the customers fall into the doughnut hole.

A contributing factor to the doughnut hole is similar to a concept from a seminal tech business book by Geoff Moore called “Crossing the Chasm.”  Moore suggests that early buyers are often visionaries with a grand vision of what they want, and no matter how clearly a vendor describes what they actually have to offer, the visionary imagines that the vendor has exactly what they want. Moore says it can be nearly impossible to make a visionary happy. The chasm is the gap between these visionary early buyers and the bigger mainstream market. You need the visionaries to stick with you and be references so you can grow your offering and cross the chasm to sell to mainstream customers, but first you need to find a way to make them happy. If you don't cross the chasm, you are stuck on the wrong side with unhappy visionary customers.

From a little less macro view, think of the visionary as the senior buyer at your customer, and think of the people who actually have to implement and deploy the system as the mainstream. The buyer had a vision and made a lot of assumptions about the system the vendor was selling.  However, decisions were made all along the implementation journey that may not quite align with the initial vision. Each deviation may have seemed small at the time, but each step off of the visionary’s path is like a grain of sand in the machinery.  Eventually, the grit adds up and the machine grinds to a halt with a very unhappy customer. Commitments and promises the visionary made to upper management are missed, and the customer is left trying to figure out what to do - get back on the bike or run away.

This is the worst possible time for a SaaS vendor to miss commitments or promises, or to be slow to respond when the customer is in a panic. Unfortunately, this moment in too many journeys aligns with the handoff doughnut hole in our support model.  This moment is when the trajectory of the relationship with the customer hangs in the balance - will they pull through and become delighted, or will they be soured and look for an exit at the earliest opportunity? Being truly customer-centric means anticipating the issues and adjusting processes to avoid the problems. ‘Keep your eye on the hole,’ and keep the customer on track for success.

What’s Wrong With Procurement?

Despite all of my years in the enterprise technology industry, every time there is a large enterprise purchaser, I am surprised and reminded of just how difficult it is to get a deal across the finish line with a big company.  Big companies develop a kind of procurement arrogance that hobbles their ability to move forward efficiently.  Internal politics and fiefdoms, and legal and IT mandates create numerous hurdles in the path of progress.  The businesspeople know what they want, but the arrogance of procurement, legal, and IT leads those groups to assume they know better, and they are the self-styled protectors of the company intent on slowing down purchases and insisting on their pet requirements, regardless of whether they make sense in the context of the business.

Our prospects are operational businesspeople, and they do not routinely buy technology products.  As a result, they don’t really know how to buy technology, or more importantly, how their organization buys technology.  That naivety leads us to face two sales cycles instead of just one.  The first cycle is to convince the business buyer that we have the platform they want.  The second cycle is to help the business buyer sell the purchase internally, and it requires us to navigate the gauntlet of all the procurement influencers and decision makers to finally get a deal signed.  The business buyer, and frankly many salespeople, are often surprised by some of the crazy demands, hurdles, and minutiae that pop up when IT, legal, and procurement get a hold of a deal.

Fortunately, an experienced enterprise sales team knows what to expect. They are adept at educating business buyers about the process early in the deal.  They tell them what is likely to happen and encourage them to get ahead of it:  engage IT early, start working with legal early, line up signers and inform everyone that the transaction is coming.  Despite our best coaching, however, some corporate bureaucracies are just insurmountable and simply must run their course.  These procurement machines become an unstoppable force - they have their “process” and nothing is going to change it. 

The good news for a SaaS business is that while we measure bookings, meaning signatures on contracts, we really focus on adding to our Annual Recurring Revenue (ARR), and we report actual revenue according to generally accepted accounting principles (GAAP), which follows a different course than bookings.  We count the full value of the deal as a booking, but we typically recognize and report license revenue over the duration of the deal.  That means a week or two delay in signing has a big impact on whether the booking is in one quarter or the next, but from a reported revenue and run-rate ARR perspective, it doesn’t have that much of an impact on a go-forward basis.  This is not to say we are indifferent to a booking being delayed from one quarter to another.  In fact, we typically manage ourselves based on quarterly bookings, and we hold our sales team (and everyone else) accountable for the bookings targets and forecasts in each quarter.  What it does mean, however, is that the most important thing is to win the deal, collect the cash, and add the customer, because that is what drives our business and revenue growth.  SaaS businesses can tolerate a little variability in when a buyer signs as long as they do in fact sign. The sales skill is to learn how to forecast accurately when you don’t know all of the procurement hurdles that have to be cleared. Too many sales people forget about the second sales cycle and stumble trying to forecast when a deal will actually close. Our sales teams need to discover the hurdles early, educate the business buyer as to what is ahead of them, and together with the buyer, manage the second-cycle as early as possible in the transaction.

Time To Lift Up The Back Foot

Often when a company decides to launch a new version of a platform, they work really hard to preserve the user interface to keep everything familiar for existing customers.  That sounds like a good goal, but it can be fraught with problems.  A clean Version 2 will have the freedom to innovate across all areas of the platform, including user interface.  Often, the interface is actually the problem that is limiting the further success of Version 1.  As products mature, they get feature after feature added to their UI, and eventually it is just too bogged down with choices and screens and options to be usable.

I experienced an example of this phenomena first-hand in the form of a new BMW versus a new Tesla.  BMW has a long history, and its interface has grown over the years.  They have strived to maintain an interface that is familiar for repeat buyers.  It was initially a clean interface, but over time it has been bogged down with baggage.  The progression started with extra buttons on the dashboard.  In time, they added similar buttons to the steering wheel.  Then they added a joystick-like device on the console to manage all the features on a video screen.  As more and more features were added, the menus on the video screen grew deeper and deeper, and it became less and less obvious where to look for the controls.  More recently, they improved the video screen to be a touch screen, and they enabled all the same features from the joystick on the touch screen.  Along the way, they added voice commands for the same features, but I don’t know anyone that is fluent enough speaking BMW to actually find all of the features.  Most recently, they added Apple Carplay with Siri, but the two voice systems are overlapping, and not compatible.  The result is a car with three or four or five different ways to do the same things.  What a jumble of interfaces!  By contrast, the Tesla has almost no buttons, and just a touch screen with limited depth of menus and a simple integrated set of voice commands (although I’m not sure anyone truly speaks the full Tesla vocabulary either).

One of my favorite sayings is “if you want to move forward, you have to pick up your back foot.”  BMW is an example of an interface where they did not pick up their back foot and drop the old ways in favor of the new.  They stayed rooted in the old and just layered on one after another duplicate controls.  The result is a complex interface that is anything but ‘ultimate.’

We have to maintain a willingness to break with the past as we innovate, and not get trapped in the BMW cycle of layering on top of layering.  As we invent new and creative ways to accomplish tasks, we have to be willing to pick up our back foot and let go of old ways.  We have to embrace the new and remove the old.  To keep it simple, we have to eliminate the complexity of too many options to achieve the same result and eliminate the tech-debt that is preventing us from building products to be what they are supposed to be.

Is It Time To Re-Platform?

When is it time to consider rebuilding a product from the ground up versus just continuing to add features?  The software landscape is littered with ‘version 2’ projects that were over-engineered and failed to see light of day.  However, on the other hand, as a product matures it tends to get featured to death and become unusable or at least unfriendly.  Like the management “Peter Principle” that describes how employees rise to their level of incompetence, when a product matures with too many add-on features and capabilities, it reaches the point where it it starts to be trapped by all the baggage.

It is a huge decision to replace a mature product with a new Version 2.  The implications go far beyond just the engineering project, and the decision has to be a cross-functional strategic one.  Having said that, companies need to be bold when the time comes to re-platform and rebuild a product.  Everyone should embark on the project with open eyes and a clear understanding of the objectives, the potential pitfalls, and the likely progression of the project.  Replacing a mature product with a new version will pass through a trough of capability, where the new product is less feature rich and less capable than the old mature product, and therefore less competitive in the marketplace.  Most companies are ‘forced’ to continue to incrementally invest in the old product to appease existing customers and remain competitive while the new product is coming up the curve.  Investment in the new product is high, and duplicative to the investment to sustain the old, and unless there is a clear plan, it can seem like the new product is constantly chasing the old but never quite surpassing it.  So, does it ever make sense to start over?

The answer is yes.  If you are considering the old product to be a problem, you can be sure your customers realized it long before you did.  You probably see it in a declining rate of expansion, or increased churn, or lower win rates, or longer sales cycles.  Maybe it is evident in less efficient engineering, or technical roadblocks to adding new capabilities.  Maybe it surfaces in increased quality problems and slower break/fix cycles due to the complexity of the code.  Maybe it only manifests in a higher volume of support calls and the need for ever increasing product training.  If you look for it, you will see that the time for re-platforming is upon you.  If you don’t see it, someone else will, and you will probably face a competitive threat challenging your market position.

We see vibrant innovation in start-up competitors that don’t have an installed base or an old product holding them back.  They are learning from your mature product and innovating a new and better approach to replace you.  If it isn’t a start-up, then one of your mature competitors is going to see opportunity and swoop in to take advantage of it.  The automobile industry and specifically the electric car revolution is a good example.  How did Tesla become one of the leading automobile manufacturers in what seemed like overnight?  To the casual observer, a Tesla may look like just another car.  It has the same basic features and capabilities as all the other cars.  However, under the covers, Tesla was designed from the ground up to be a new, ‘version 2’ of an automobile.  It was built to be new and better, and to replace the status quo.  By contrast, most traditional cars were designed and built in a different era with different concepts, and they have a lot of history and features from times gone by.  They have an installed base and entrenched engineering and production.  In software terms, they have a lot of tech-debt, and they were resting on their laurels of past success.   With its clean modern architecture and design, Tesla created a platform for innovation that can be enhanced and improved at a pace well beyond what traditional manufacturers could achieve.

When a product is built from a clean slate, it eliminates the tech-debt.  With no tech-debt, all of the investment in engineering is directed toward innovation, and the product can move forward faster than competitors that are struggling with baggage.  When it is done well, ‘Version 2’ delivers a springboard to the future, and it enables you to set the pace for the market.

The challenge is that troublesome trough of capability.  A common term used to describe the design point for a first commercial release is ‘minimum viable product’ (MVP).  There are a few problems with this concept.  First, it has to be defined in the context of a market segment with a clear value proposition.  If Version 2 is slated to enter the exact same market as Version 1, then to be viable it will need to compete at least as effectively upon launch.  To do so, it will have to be feature rich, so ‘minimum’ is really not aligned with the market if the goal is to be ‘viable.’  One approach is to design Version 2 for a different market or sub-segment where limited features can still deliver a value proposition that is viable.  This could be a down-market offering.  Maybe the mature product addresses the needs of large global organizations with multiple languages and currencies, while the early release of Version 2 could target smaller companies that don’t have the same global requirements.  Perhaps the points of enterprise integration or flexibility of configuration can be limited on initial release if the target buyer is less demanding.  The key is to select a market segment where Version 2 in its early form can in fact be viable*. 

Once launched, the market can lead the growth of the product.  The ultimate goal may be to make Version 2 so attractive that traditional customers of Version 1 will find it compelling to adopt even if they have to give up some of their existing V1 features.  Alternatively, Version 2 may open the door to a new and potentially larger market than Version 1 ever could address, and it could facilitate a corporate pivot to a steeper success curve.  The most challenging design point for Version 2 is to attempt to launch with greater capabilities than Version 1.  It has been done, but this is the scenario that typically leads to over-engineering Version 2, and greatly increases the risk of never crossing the finish line.

* Note: I have a real problem with the term ‘minimum viable product - MVP.’ It sounds like the commercial that talked about aspiring to be ‘mediocre.’ Products should aspire to be ‘successful’ not just viable. I insist on aiming for the ‘minimum successful product -MSP’, which has a higher goal than simply being viable.

Innovation Or Invention

We can always dream up more product bells and whistles, but the important ones truly advance the flexibility of a product to meet real world needs.  When allocating resources, we have to balance the desire to boldly go where no product has gone before, with the mundane need to fix ‘broken windows’ and put a fresh coat of paint on tired older elements of the foundation.  I am an advocate of periodically requiring the product/engineering team to perform an entire customer implementation from start to finish.  Three benefits will come of it.  The first is it will highlight for the product/engineering team all the places where “people putty” is required to fill a gap in deploying the product.  The benefit of closing the gaps will be a significant increase in implementation efficiency, shorter launch windows, and faster time to value for customers.  Secondly, it will build a stronger understanding of the customers’ journey and needs, and hopefully create more empathy.  Lastly, it will serve as an engine for innovation.

How many times have you had the experience of doing something and when you finished you suddenly had a flash of an idea about how you could have done it better or differently.  To innovate you need to understand the status quo so that you know what you are innovating and why.  There is a difference between innovation and invention.  Invention is creating something new and unique.  According to the U.S. Patent office “an invention can only be considered patent-eligible if it is new, non-obvious, and useful.”  This is in the camp of boldly going where no product has gone before, and for a portion of our product / engineering journey, we need to be on the path to creating capabilities that meet this definition.  However, we also need to invest in the more mundane innovations that simply ensure we have the best product on the market.