Recruiting End Users For Enterprise Software Applications

As I work with a few enterprise software start-ups I often get asked about how to find early customers to validate and refine early design prototypes. The answer is surprisingly not that complicated. The following is my response to a recent question on Quora, "How do we get a target audience for enterprise applications, when you dont have an enterprise customer yet for rapid prototyping?"

Finding a customer and finding end users are quite different. In enterprise software end users are not the buyers and the buyer (customer) may or may not use your software at all. To recruit end users, there are three options:

Friends and families: Use your personal connections through email and social media channels and ask for their time (no more than 30 minutes) to conduct contextual inquiries and get validation on your prototypes. Most people won't say no. Do thank them by giving them a small gift or a gift card.

Find paid end users: This does seem odd but it works. I know of a few start-ups that have used this method effectively. Use Craigslist and other means to recruit people that match your end user role and pay them to participate in feedback sessions. It is worth it.

Guerrilla style: Go to a convention or a conference where you could find enough end users that fit your profile. Camp out at the convention with swag and run guerrilla style recruiting to validate and prototype. Iterate quickly, preferably in front of them, and validate again.

A Design Lesson: Customers Don't Remember Everything They Experience

My brother is an ophthalmologist in a small town in India. In his private practice, patients have two options to see him: either take an appointment or walk in. Most patients don't take an appointment due to a variety of cultural and logistics reasons and prefer to walk in. These patients invariably have to wait anywhere from 15 minutes to an hour and half on a busy day. I always found these patients to be anxious and unhappy that they had to wait, even if they voluntarily chose to do so. When I asked my brother about a possible negative impact due to unhappiness of his patients (customers) he told me what matters is not whether they are unhappy while they wait but whether they are happy or not when they leave. Once these patients get their turns to see my brother for a consultation, which lasts for a very short period of time compared to how much they waited, my brother will have his full attention to them and he will make sure they are happy when they leave. This erases the unpleasant experience from their minds that they just had it a few minutes back.

I was always amused at this fact until I got introduced to the concept of experience side versus memory side by my favorite psychologist Daniel Kahneman, explained in his book Thinking, Fast and Slow and in his TED talk (do watch the TED talk, you won't regret it). While the patients waited the unpleasant experience was the experience side which they didn't remember and the quality time they spent in the doctor's office was the memory side that they did remember.

Airlines, hotels, and other companies in service sectors routinely have to deal with frustrated customers. When customers get upset they won't remember series of past good experiences they had but they would only remember how badly it ended - a cancelled flight, smelly hotel room or production outage resulting in an escalation. Windows users always remember the blue screen of death but when asked they may not necessarily remember anything that went well on a Windows machine prior to a sudden crash resulting into the blue screen of death. The end matters the most and an abrupt and unrecoverable crash is not a good end. If the actual experience matters people will perhaps never go back to a car dealership. However people do remember getting a great deal in the end and forget the misery that the sales rep put them through by all the haggling.

Proactive responses are far better in crisis management than reactive ones but reactive responses do not necessarily have to result in a bad experience. If companies do treat customers well after a bad experience by being truly apologetic, responsive, and offering them rewards such as free upgrades, miles, partial refund, discounts etc. people do tend to forget bad experiences. This is such a simple yet profound concept but companies tend not to invest into providing superior customer support. Unfortunately most companies see customer support as cost instead of an investment.

This is an important lesson in software design for designers and product managers. Design your software for graceful failures and help people when they get stuck. They won't tell you how great your tool is but they will remember how it failed and stopped them from completing a task. Keep the actual user experience minimal, almost invisible. People don't remember or necessary care about the actual experiences as long as they have aggregate positive experience without hiccups to get their work done. As I say, the best interface is no interface at all. Design a series of continuous feedback loops at the end of such minimal experiences—such as the green counter in TurboTax to indicate tax refund amount—to reaffirm positive aspects of user interactions; they are on the memory side and people will remember them.

In enterprise software, some of the best customers could be the ones who had the worst escalations but the vendors ended their experience on a positive note. These customers do forgive vendors. As a vendor, a failed project receives a lot worse publicity than a worst escalation that could have actually cost a customer a lot more than a failed project but it eventually got fixed on a positive note. This is not a get-out-of-jail-free-card to ignore your customers but do pause and think about what customers experience now and what they will remember in future.

Photo courtesy: Derek 

Focus On Abstraction And Not Complexity

I am a big fan of software design patterns. A design pattern is a general reusable solution to a commonly occurring problem within a given context. Software design patterns are all about observing technical abstractions in complex problems by identifying patterns and applying well known solutions to them.

My management style is largely based on abstractions. When things get muddy I step away from complexity for a few minutes and explore abstractions. This helps me keep in touch with the bigger picture while I look for solutions to a given problem. When you're too close to a topic you do tend to fixate on complexity leaving sight of the bigger picture. I make a conscious attempt to go between complexity and abstraction when I need to. And, that's perhaps the only way to manage it effectively in pursuit of working smart and not just working hard. Complexity invariably makes people get into an analysis paralysis mode resulting into a decision gridlock that affects the bigger picture. In many cases, not being able to make a decision has far worse consequences than not solving a problem which may or may not be important in long run. Abstracting complexity helps me make a decision with focus on consequences as opposed to a short term solution. Abstraction also allows me to spot behavioral and systemic problems as opposed to tactical and temporal problems.

Ask yourself what you remember the most about a couple of complex problems that you solved last year and the answer most likely won't be how great your solution was but it very well would be what the problem actually taught you. It's not the complexity that you will cherish but the simplicity, the abstracted experience, is what will stay with you for the rest of your life to help you find solutions to similar problems in future.

Photo courtesy: miuenski 

Challenges For On-premise Vendors Transitioning To SaaS

As more and more on-premise software vendors begin their journey to become SaaS vendors they are going to face some obvious challenges. Here's my view on what they might be.

The street is mean but you can educate investors

Sharp contrast between Amazon and Apple is quite clear. Even though Amazon has been in business for a long time with soaring revenue in mature categories the street sees it as a high growth company and tolerates near zero margin and surprises that Jeff Bezos brings in every quarter. Bezos has managed to convince the street that Amazon is still in heavy growth mode and hasn't yet arrived. On the other hand despite of Apple's significant revenue growth—in mature as well as in new disruptive categories—investors treat Apple very differently and have crazy revenue and margin expectations.

Similarly, traditional pure SaaS companies such as Salesforce is considered a high growth company where investors are focused on growth and not margins. But, if you're an on-premise vendor transitioning to SaaS the street won't tolerate a hit on your margins. The street would expect mature on-premise companies to deliver on continuous low double digit growth as well as margins without any blips and dips during their transition to SaaS. As on-premise vendors change their product, delivery, and revenue models investors will be hard on them and stock might take a nosedive if investors don't quite understand where the vendors are going with their transition. As much as investors love the annuity model of SaaS they don't like uncertainty and they will punish vendors for lack of their own understanding in the vendor's model. It's a vendor's job to educate investors and continuously communicate with them on their transition.

Isolating on-premise and SaaS businesses is not practical

Hybrid on-premise vendors should (and they do) report on-premise and subscription (SaaS) revenue separately to provide insights to investors into their revenue growth and revenue transition. They also report their data center related cost (to deliver software) as cost of revenue. But, there's no easy way, if at all there's one, to split and report separate SG&A costs for their on-premise and SaaS businesses. In fact combined sales and marketing units are the weapons incumbents on-premise vendors have to successfully transition to SaaS. More on that later in this post.

The basic idea behind achieving economies of scale and to keep the overall cost down (remember margins?) is to share and tightly integrate business functions wherever possible. Even though vendors sometime refer to their SaaS and on-premise businesses as separate lines of businesses (LoBs), in reality they are not. These LoBs are intertwined that report numbers as single P&L.

Not being able to charge more for SaaS is a myth

Many people I have spoken to assume that SaaS is a volume-only business and you can't charge customers what you would typically charge your customers in your traditional license and maintenance revenue business model. This is absolutely not true. If you look at some of the deal sizes and length of SaaS contracts of pure SaaS companies they do charge a premium when they have unique differentiation regardless of volume. Customers are not necessarily against paying premium - for them it is all about bringing down their overall TCO and increasing their ROI with reduced time to value. If a vendor's product and its delivery model allow customers to accomplish these goals they can charge them premium. In fact in most cases this could be the only way out. As a vendor transitioning from on-premise to SaaS their cost is going to go up; they will continue to invest into building new products and transitioning existing products and they will significantly assume the cost of running operations on behalf of their customers to deliver software as a service. They not only will have to grow their top-line to meet the growth expectations but to offset some of the cost to maintain the margins.

Prime advantage on-premise incumbents have over SaaS entrants

So, what does work in favor of on-premise vendors who are going through this transition?

It's the sales and marketing machine, my friends.

The dark truth about selling enterprise software is you need salespeople wearing suits driving around in their BMWs to sell software. There's no way out. If you look at high growth SaaS companies they spend most of what they earn on sales and marketing. Excluding Workday there is not much difference in R&D cost across vendors, on-premise or SaaS. Workday is building out its portfolio and I expect to see this cost go down in a few years.

Over a period of time, many on-premise vendors have built a great brand and achieved amazing market penetration. As these vendors go through SaaS transition they won't have to spend as much time and money educating the market and customers. In fact I would argue they should thank other SaaS vendors for doing the job for them. On-premise vendors have also built an amazing sales machine with deep relationship with customers and reliable sales processes. If they can maintain their SG&A numbers they will have enough room to deal with a possible initial hit on revenue and additional cost they would incur as they go through this transition.

Be in charge of your own destiny and be aggressive

It's going to be a tough transition regardless of your loyal customer base and differentiating products. It will test the execution excellence of on-premise vendors. They are walking on a tight rope and there's not much room to make mistakes. The street is very unforgiving.

Bezos and Benioff have consistently managed to convince the street they are high growth companies and should be treated as such. There's an important lesson here for on-premise vendors. There is no reason to label yourself an on-premise vendor simply making a transition. You could do a lot more than that; invest into new disruptive categories and rethink existing portfolio. Don't just chase SaaS for its subscription pricing but make an honest and explicit attempt to become a true SaaS vendor. The street will take a notice and you might catch a break.

Rise Of Big Data On Cloud

Growing up as an engineer and as a programmer I was reminded every step along the way that resources—computing as well as memory—are scarce. The programs were designed on these constraints. Then the cloud revolution happened and we told people not to worry about scarce computing. We saw rise of MapReduce, Hadoop, and countless other NoSQL technology. Software was the new hardware. We owe it to all the software development, especially computing frameworks, that allowed developers to leverage the cloud—computational elasticity—without having to understand the complexity underneath it. What has changed in the last two to three years is a) the underlying file systems and computational frameworks have matured b) adoption of Big Data is driving the demand for scale out and responsive I/Os in the cloud.

Three years back, I wrote a post, The Future Of The BI In Cloud where I had highlighted two challenges of using cloud as a natural platform for Big Data. The first one was to create a large scale data warehouse and the second was lack of scale out computing for I/O intensive applications.

A year back Amazon announced RedShift, a data warehouse service in the cloud, and last week they announced high I/O instances for EC2. We have come a long way and more and more I look at the current capabilities and trends, Big Data, at scale, on the cloud, seems much closer to reality.

From a batched data warehouse to interactive analytic applications:

Hadoop was never designed for I/O intensive applications, but Hadoop being a compelling computational scale out platform developers had a strong desire to use it for their data warehousing needs. This made Hive and HiveQL popular analytic frameworks but this was a sub optimal solution that worked well for batch loads and wasn't suitable for responsive and interactive analytic applications. Several vendors realized there's no real reason to stick to the original style of MapReduce. They still stuck to the HDFS but significantly invested into alternatives to Hive which are way faster.

There are series of such projects/products that are being developed on HDFS and MapReduce as a foundation but by adding special data management layers on top of it to run interactive queries much faster compared to plain vanilla Hive. Some of those examples are Impala from Cloudera and Apache Drill from MapR (both based on Dremel), HAWQ from EMC, Stinger from Hortonworks and many other start-ups. Not only vendors but the early adopters such as Facebook created Hive projects such as Presto, an accelerated Hive, which they recently open sourced.

From raw data access frameworks to higher level abstraction tools: 

As vendors continue to build more and more Hive alternatives I am also observing vendors investing in higher level abstraction frameworks. Pig was amongst those first higher level frameworks that made it easier to express data analysis programs. But, now, we are witnessing even higher layer rich frameworks such as Cascading and Cascalog not only to write SQL queries but write interactive programs in higher level languages such as Clojure and Java. I'm a big believer in empowering developers with right tools. Working directly against Hadoop has a significant learning curve and developers often end up spending time on plumbing and other things that can be abstracted out in a tool. For web development, popularity of Angular and Bootstrap are examples of how right frameworks and tools can make developers way more efficient not having to deal with raw HTML, CSS, and Javascript controls.

From solid state drives to in-memory data structures: 

Solid state drives were the first step in upstream innovation to make I/Os much faster but I am observing this trend go further where vendors are investing into building in-memory resident data management layers on top of HDFS. Shark and Spark are amongst the popular ones. Databricks has made big bets on Spark and recently raised $14M. Shark (and hence Spark) is designed to be compatible with Hive but designed to run queries 100x times faster by using in-memory data structures, columnar representation, and optimizing MapReduce not to write intermediate results back to disk. This looks a lot like MapReduce Online which was a research paper published a few years back. I do see a UC Berkeley connection here.

Photo courtesy: Trey Ratcliff

How I Accomplished My Personal Goal Of Going To Fewer Meetings

As part of my job I have to go to a lot of meetings. As it turns out, all meetings are not equally important. Many times, either during a meeting or after the meeting, I end up asking myself why the hell did I go to this meeting. Sounds familiar?

A couple of yeas back, instead of just whining about it, I decided to do something about this situation. I set a personal goal to cut down the meetings that I would go to by 20%. Not only I succeeded but I kept the same goal the year after and I accomplished that as well.

This is how I did it:

Ask for prep documents and an upfront agenda

If the meeting that I am invited to does not have an agenda in the meeting request, I ask for it before I commit to it. This approach has two positive effects: 1) it forces an organizer to think what he/she wants to accomplish that invariably results in a productive meeting b) I have an opportunity to opt out if I don't receive an agenda or the agenda doesn't require my presence. I also ask for prep documents for a meeting; I prepare for all my meetings and I firmly believe that meeting time should be judiciously used to discuss what people think about the information and make important decisions as opposed to gathering information that could have been accomplished prior to a meeting.

Opt-out with an alternative ahead of a meeting

If I believe the agenda is partially useful but I won't add any value by being part of the meeting, I connect with an organizer ahead of the meeting to clarify a few things or give my input, either in person or via email or phone. In most cases, me reaching out to an organizer serves the purpose and I don't have to go to the actual meeting. If I do end up having to go for such meetings I ask an organizer for a permission to either walk-in late or leave early. This saves me a lot of time and I don't have to sit through a meeting when I am not required to be there.

Postpone a non-critical meeting

If I see that I am invited to a non-critical meeting, I ask to postpone it by a few days citing my non-availability. In many cases, the issue would have been resolved in a few days and we won't be required to meet. It is important to decline the original meeting request and ask the organizer to create a new meeting request in future even if you have an intent to postpone and not cancel the meeting. Most people don't create a new meeting request and I won't hear back from them.

DVR the meeting

I ask organizers to record certain meetings when I believe that parts of a meeting would be useful at later stage. I fast forward non-interesting parts of such meetings and listen to the parts that I like. I underestimated the effectiveness of listening to a recording until I organized a few meetings as podcasts and listened to them during my commute. Most fascinating part of this approach, other than an ability to fast forward, is being able to listen to a meeting as an information session without having to worry about understanding all details and anxiety to make decisions.

If everything else fails, multitask

I believe it is somewhat rude and distracting to others when people bring their laptops/tablets to a meeting and keep working on it and not pay attention to the meeting. But, this isn’t true when the meeting is an audio conference. I don't work on my laptop or tablet when I am in a meeting room; I am fully committed to the meeting and completely present. However, for certain meetings, when I know that I don't have an option to opt out and it is going to be a waste of time, I dial into the meeting instead of being there in person. I do continue to work on my laptop while participating into the meeting. This is not to confuse with remote meetings that I participate in or lead when all people are not at the same location. I am fully present for those meetings.

Before you ask, yes, I did meticulously measure the time I saved. I had a simple spreadsheet that did a great job. I was a little hesitant in the beginning to push back for meetings but l became more comfortable as I started saving more and more time. I would highly encourage you to follow these rules or create your own and save yourself some quality time that you can use do other useful things.

Photo courtesy: Ho John Lee

Big Data Platform As Technology Continuum

Source: Wikipedia

A Russian chemist, Dimitri Mendeleev, invented the first periodic table of elements. Prior to that, scientists had identified a few elements but the scientific world lacked a consistent framework to organize these elements. Dimitri built upon existing work of these scientists and invented the first periodic table based on a set of design principles. What fascinates me more about his design is that he left a couple of rows empty because he predicted that new elements would be discovered soon. Not only he designed the first periodic table to create a foundation for how elements can be organized but he anticipated what might happen in future and included that consideration in his design.    

It is unfortunate that a lot of us are trained to chase a perfect answer as opposed to designing something that is less than perfect, useful, and inspirational to future generations to build on it. We look at technology in a small snapshot and think what it can do for me and others now. We don't think of technology disruption as a continuum to solve a series of problems. Internet started that way and the first set of start-ups failed because they defined the problem too narrowly. The companies that succeeded such as Google, Amazon, eBay etc. saw Internet as a long term trend and didn't think of it in a small snapshot. Cloud and Big Data are the same. Everyday I see problems being narrowly defined as if this is just a fad and companies want to capitalize on it before it disappears.

Build that first element table and give others an imagination to extend it. As an entrepreneur you were not the first and you are not going to be the last trying to solve this problem.