There is a dark secret about the data warehousing industry that no one ever seems to acknowledge, which I’m going to expose in this section. You often hear of the failure of a data warehouse along with a lot of different technical reasons why it didn’t work, why users found it too hard to use, etc. Surprisingly, even data warehouse implementations that were consider a success from a technical standpoint can be deemed a failure by the business users. Why can that happen? You’re about to find out…
Before we get there, let’s have a discussion about computer systems. In my mind, there are two classifications of computer systems: the must haves and the nice to haves. The must haves represent systems that the business would crumble without. These are systems like financial systems where you enter vendor invoices so that they can be paid, or you enter customer invoices so that the customer can be billed and they can pay you. Without systems like these, it would be very difficult, if not impossible, to run your business efficiently. Some would argue that without these systems, your business would die. The nice to haves are systems that could be considered to be optional. These are systems that if they are not in place, the business will survive. The business may run a bit less efficiently, but there’s not a worry that the business would crumble. In many industries, data warehouses are considered a nice to have. There are a few industries where without them a business would be extremely limited, but not a whole lot of cases where a business would die without one.
In my years at DecisionPoint, I experienced a lot of sales situations where we would get really close to closing a deal, but the customer would lose their budget, the money they had budgeted would go for another IT priority, or something else of that nature. If the customer walked away from us, the business was not going to die. Sure, the company could greatly benefit from the data warehouse, but there was no risk to doing nothing. No money spent, no risk of failure, etc. I think that’s what makes selling data warehouse solutions such a tough business. Anytime the customer has a “do nothing” option, it’s always something to worry about. There has to be a motivator or compelling reason that causes them to not choose the “do nothing” option.
There’s another “do nothing” option that never gets mentioned by IT shops, consultants, or vendors. That “do nothing” option lies on the other side of a successful implementation. Let’s assume that you went through a lot of trouble and hassle, but you got the data warehouse up and running with end users actively using it. You think all is well and good, but there doesn’t seem to be any benefit from the data warehouse. All of the business value (i.e. increased revenue, reduced cost), etc. just doesn’t materialize, and you wonder why…The answer lies below, and involves something that is often referenced in terms of Psychology.
Anyone that has been through or knows about counseling should know the answer to this question. If you’re going to a counselor, when do you start to get better? The answer is you start to get better when you decide to get better. The counselor can talk to you for hours and make many suggestions and recommendations. However, if you don’t decide you want to get better, you won’t try the suggestions or recommendations. The counseling sessions will simply be an hour or so of your time talking to someone. There is no benefit, and you’re probably wasting a lot of money.
Now, let’s spin this in the direction of the data warehouse. Using our scenario above, we’ve done everything that needs to be done and the users are using the data, but nothing changes in the business. It’s quite possible that the data warehouse is providing valuable information, but the users are too afraid or unable to use the data in making changes in the business that will improve revenue or reduce expenses. Just like a counselor, the data can tell you all of these wonderful things about the business, but unless the users are willing to use that information to make changes in the business, nothing will happen. Your data warehouse is just like the counselor…you’ve spent a lot of money, but nothing changes because you haven’t decided that you need to get better.
It amazes me how often this happens, and what a difference it makes when you have end users that are willing, able, and brave enough to do what needs to be done after the data points them in the right direction. Far too often, I have seen data warehouse projects go down in flames or be viewed as wasted money simply because the end users didn’t have the guts to do something, or worse yet, management wouldn’t let them do what needed to be done. Generally speaking, people hate change. A data warehouse is the first step to change. It tells you how things are so you can see where you need to go. Getting there involves change, and in some cases, change represents a bad thing. Don’t rock the boat…you might get in trouble or be fired. Willingness to accept and use the data as a “business weapon” is the only way to succeed.
A couple of examples to make my point… The names are left out to avoid any kind of aggravation I might receive from the people that were involved.
In the early days of DecisionPoint, I was helping a customer in the Northeast United States implement our data warehouse. It was about 8-12 weeks of me flying back and forth across the country to put it in for them. We had some bumps along the way, but after we worked through the bumps, we ran into a brick wall. Everything was looking good, and I was demoing it to an end user and we started to look at some data. We got to one section of the data and she made a comment to me something like this. “You have to turn this off!” My immediate response was to ask why we had to do that after everything we had done. Her response went like this: “Your numbers are correct, but that’s not what the CFO believes the business looks like…” It turns out that they did have some minor problems with some of the transactions where the data came from. That was fixable. What was not fixable was her unwillingness to go to the CFO, present the information, and figure out a way forward. I left that company and have not heard back from them since.
On the other side of the equation, we have two really positive stories to tell.
In our fist example, it was again the early days of DecisionPoint. We were working with a local company implementing our software. It was fun because they were a retailer, and when it comes to change retailers don’t mess around. If they find something that will eliminate costs or increase revenue, they’ll do it…no questions asked. However, it does get a bit cut throat as there is “no mercy” in what they do. They may make a change in one day that puts 100 people out of work, and their attitude is “so be it, we had to do it for the good of the business”. In any event, we were only a couple of weeks into our implementation when we gave the end users their first glimpse of the data. They were focused on the profitability of the stores. They started to look at the unprofitable stores, and guess what? For the ones that were in real trouble, they literally started to shut them down the next day. No questions asked. This was long before they were even actively using the data. They saw a problem. They fixed it. In the end, it did help them save a lot of costs and have a higher profitability than they would have had, so it was a good thing.
Another example at this same company came later on in the implementation. We were extracting vendor invoices, and everything was going smoothly. Then, we got to a point where we were extracting data for the month of December. Suddenly, the vendor invoice volume quadrupled. We were shocked and puzzled, and when we presented it to the end users, they had the same reaction. They were determined to find the source of this phenomenon, and proceeded to do research. To make a long story a bit shorter, here goes. When they would hire a store manager, the manager would get a bonus each month related to the profitability of the store. So, the managers had creatively figured out that if they didn’t turn in their vendor invoices (i.e. expenses), the store was more profitable. So, for the first eleven months of the year, they wouldn’t turn in any expenses. Then, in December, they would send in all of the vendor invoices they had collected over the year. The problem was not only vendors that were upset about not being paid, but it ran deeper. It turns out that the stores were also getting late notices on vendor invoices. So, what happened in December is that the AP clerks would enter the original invoice, then enter the late notices, etc. In some cases the company was double, triple, or even quadruple paying vendors. What seemed to be a very simple problem was costing them a lot of money. Needless to say, the bonus program was changed, and the problem disappeared.
My last example is a story of a user using some data in a way that even I wouldn’t have guessed. This person gets the gold star from me on “data creativity”. At another one of our retail accounts, there was a user in what is called their “Risk Management” department. Part of that department involved insurance policies. This particular business had a lot of delivery vans throughout the US that they were using along with associated insurance policies on each van. This particular person did some analysis using some vendor invoice data that allowed her to compare what they were spending on new tires for the vans in each region of the country, and then compared that to the insurance rates they were paying on each van. It turned out that the regions that spent more money on tires for the vans had vans with fewer accidents, which meant that their insurance rates were lower. Using this information, the user instituted a corporate wide policy on how often the vans would get new tires, so that all regions were doing the same thing. Once she changed the policy, they began to save millions of dollars on their insurance policies. In this case, not only did you have an end user willing to act on the data, but also one creative enough to find out something about the business most people would have overlooked.
OK, so what’s the moral of the story? It’s very simple. When it comes to a data warehouse, the business only improves when the users are willing and able to act on the information that they see. If they are unwilling or unable due to a management policy or something like that, the data warehouse will die a slow painful death. Could it have been useful? Yes. But, potential only goes so far…you have to use the potential before anything changes.
Thursday, June 17, 2010
Sunday, June 6, 2010
Dare To Do Things Differently
At DecisionPoint, I often describe our evolution as a company in the form of management regimes. When I use the term regime, I talk about the management team. Generally, in any company, when a CEO is hired, they will more than likely bring in people that they have worked with before at other companies, and that they also trust. Trust is an especially important trait as you want to make sure that when it comes time to make tough decisions, you are working with the people that you trust will help you make the right decision.
I experienced four different management regimes at DecisionPoint, each with its own “personality”. In other words, there were four different CEO’s that I worked for, each of which brought in their own set of management team members based on past work experiences and relationships. While regimes can provide a consistency from a management team perspective, there is also a pitfall associated with a regime. In this chapter of the book, I will describe each regime, but then follow it up with what I consider to be the pitfall to the regime concept.
Our first regime at DecisionPoint was what I called the “Teradata Regime”. Our first CEO was an ex-Teradata employee, and when he was brought on board as our CEO, he proceeded to hire a VP of Sales, a VP of Marketing, and several other non-management personnel that were either people he worked with directly or indirectly at Teradata. In some respects, what the first CEO wanted to do was to bring the positive traits he experienced at Teradata to DecisionPoint. Under the “Teradata Regime”, there was a good understanding of our product as both Teradata and DecisionPoint were suppliers of data warehouse solutions. However, in the world of Teradata, hardware and software were bundled, and in the world of DecisionPoint, we were focused solely on software. So, some of the things that the “Teradata Regime” wanted to implement did not apply to what we did at DecisionPoint as those things were more related to how you sell bundled hardware and software versus a pure software solution.
Our second regime at DecisionPoint was what I called the “Sequent Regime”. Our second CEO was an ex-Sequent employee. Initially, the main employees that came from Sequent were the team he inherited (i.e. the engineer and sales teams that were spun out of Sequent). The one thing that the second CEO initially did, which was good, was he understood our product was software, and began looking for sales people that sold software rather than try and convert hardware sales reps from Sequent into software sales people. However, as the second CEO began to build the headquarters staff at DecisionPoint (i.e. marketing, professional services, etc.), he tapped into his network of people he had worked with at Sequent. From a marketing and professional services perspective, Sequent understood data warehousing and the separation between hardware and software. However, all of Sequent’s data warehouse experience was based on professional services people building custom data warehouses specific to each customer where as DecisionPoint was providing a packaged data warehouse environment. What happened over time is that our product became less packaged, and our staff of professional services people grew significantly. A lot of the customers ended up spending more money on the professional services than they did on the software, and that was contrary to what our goals were at the corporate level.
Our third regime at DecisionPoint was what I called the “Brio Regime”. Our third CEO was the founder of Brio, but no longer part of Brio. Like the other CEO’s, he brought on board a lot of ex-Brio people. Brio provided an end user tool that made data easier to access. DecisionPoint’s product was based on building a robust set of data and infrastructure, not on the tools the end user uses to access the data. The folks that came from Brio were intensely focused on the tool that users used to access the data versus the content of the data. Through the “Brio Regime”, DecisionPoint spent a significant amount of money making a robust tool that was integrated with the data warehouse environment, and provided an easy environment for end users to access data in the data warehouse. Unfortunately, we lost focus on our core value (robust data warehouse environment), and spent a lot of engineering time and money on tools that were good, but not really part of the core value of our product offering.
The fourth and final regime was what I called the “Informatica Regime”. Our fourth CEO was and ex-Informatica employee, and was someone that was introduced to us via the venture capitalist that provided us one of our rounds of funding. The fourth CEO did not immediately replace the existing management team with ex-Informatica people that he had worked with. However, over time, our VP of Sales, our VP of Marketing, and several sales people were ex-Informatica people. From a data warehousing perspective, our fourth CEO understood our value proposition from a data warehouse solution perspective very well. What we were doing with our products matched something he was trying to do at Informatica. However, Informatica was an infrastructure (i.e. ETL – extract, transform, load) company, and really understood the requirements for moving data from a variety of source systems into a data warehouse. While DecisionPoint had infrastructure components, the real value was in the type of data we provided, and how we structured that data for end users.
I will not judge what I thought were the good and bad points of each management regime. That is water under the bridge. However, the point to take away from this is the effect that regimes have on a startup. In each regime we had at DecisionPoint, they all came from the data warehousing industry, but each had a different focus within that industry. Because DecisionPoint products span many different aspects of the data warehousing industry, we had components of our product set that each regime understood really well and others they did not understand very well. Generally, each regime tended to focus on the components of the DecisionPoint products that they understood the best, rather than focusing on the overall DecisionPoint solution. This led to different sales and marketing positioning that each regime used even though the DecisionPoint product was the same across all regimes.
The good thing about regimes is that they bring valuable past experiences about what has worked for them successfully. However, the pitfall of the regime mentality is that you don’t think “out of the box” in many cases. Management regimes will often do what worked for them in the past, especially when it comes to sales and marketing. In many cases, what worked in the past does not apply to the current situation. Probably the most obvious example I have from DecisionPoint is in how our product was sold. The consistent theme across all management regimes at DecisionPoint (and is generally true in the high end software market) is to establish a high touch sales force goaled on selling a lot of software to large customers. Each regime thought that they would be the one to finally make the high touch sales model work better than the last one did. They each thought that if they worked at it a little harder (better sales reps, better training, etc.), they could crack the code for how to sell DecisionPoint products with a larger high touch sales force. None of them put any serious effort to completely rethink how the product should be sold. In the third management regime, we attempted a low end offering that would be ideal for middle and small market customers, but the sales force quickly rejected it. The bottom line is that if your sales force rejects it, they won’t sell it. Unfortunately, management at the time did not address the issue with the sales force, so the product offering died a slow, painful death.
The bottom line of the whole story and our different management regimes is that no matter what you do or who is involved, you have to be willing to try new and different things. Doing the same thing as you've done, unsuccessfully, before while working just a bit harder doesn't necessarily result in improvement. You always have to be willing to look at what you're doing, where you've been, and change course appropriately. Everyone brings valuable experience to a startup. However, if you only use that experience to do what you've done before, you're selling yourself and the startup short. Be bold, do something differently than it's ever been done before, and be confident that no matter what you do, you can adjust and move forward.
I experienced four different management regimes at DecisionPoint, each with its own “personality”. In other words, there were four different CEO’s that I worked for, each of which brought in their own set of management team members based on past work experiences and relationships. While regimes can provide a consistency from a management team perspective, there is also a pitfall associated with a regime. In this chapter of the book, I will describe each regime, but then follow it up with what I consider to be the pitfall to the regime concept.
Our first regime at DecisionPoint was what I called the “Teradata Regime”. Our first CEO was an ex-Teradata employee, and when he was brought on board as our CEO, he proceeded to hire a VP of Sales, a VP of Marketing, and several other non-management personnel that were either people he worked with directly or indirectly at Teradata. In some respects, what the first CEO wanted to do was to bring the positive traits he experienced at Teradata to DecisionPoint. Under the “Teradata Regime”, there was a good understanding of our product as both Teradata and DecisionPoint were suppliers of data warehouse solutions. However, in the world of Teradata, hardware and software were bundled, and in the world of DecisionPoint, we were focused solely on software. So, some of the things that the “Teradata Regime” wanted to implement did not apply to what we did at DecisionPoint as those things were more related to how you sell bundled hardware and software versus a pure software solution.
Our second regime at DecisionPoint was what I called the “Sequent Regime”. Our second CEO was an ex-Sequent employee. Initially, the main employees that came from Sequent were the team he inherited (i.e. the engineer and sales teams that were spun out of Sequent). The one thing that the second CEO initially did, which was good, was he understood our product was software, and began looking for sales people that sold software rather than try and convert hardware sales reps from Sequent into software sales people. However, as the second CEO began to build the headquarters staff at DecisionPoint (i.e. marketing, professional services, etc.), he tapped into his network of people he had worked with at Sequent. From a marketing and professional services perspective, Sequent understood data warehousing and the separation between hardware and software. However, all of Sequent’s data warehouse experience was based on professional services people building custom data warehouses specific to each customer where as DecisionPoint was providing a packaged data warehouse environment. What happened over time is that our product became less packaged, and our staff of professional services people grew significantly. A lot of the customers ended up spending more money on the professional services than they did on the software, and that was contrary to what our goals were at the corporate level.
Our third regime at DecisionPoint was what I called the “Brio Regime”. Our third CEO was the founder of Brio, but no longer part of Brio. Like the other CEO’s, he brought on board a lot of ex-Brio people. Brio provided an end user tool that made data easier to access. DecisionPoint’s product was based on building a robust set of data and infrastructure, not on the tools the end user uses to access the data. The folks that came from Brio were intensely focused on the tool that users used to access the data versus the content of the data. Through the “Brio Regime”, DecisionPoint spent a significant amount of money making a robust tool that was integrated with the data warehouse environment, and provided an easy environment for end users to access data in the data warehouse. Unfortunately, we lost focus on our core value (robust data warehouse environment), and spent a lot of engineering time and money on tools that were good, but not really part of the core value of our product offering.
The fourth and final regime was what I called the “Informatica Regime”. Our fourth CEO was and ex-Informatica employee, and was someone that was introduced to us via the venture capitalist that provided us one of our rounds of funding. The fourth CEO did not immediately replace the existing management team with ex-Informatica people that he had worked with. However, over time, our VP of Sales, our VP of Marketing, and several sales people were ex-Informatica people. From a data warehousing perspective, our fourth CEO understood our value proposition from a data warehouse solution perspective very well. What we were doing with our products matched something he was trying to do at Informatica. However, Informatica was an infrastructure (i.e. ETL – extract, transform, load) company, and really understood the requirements for moving data from a variety of source systems into a data warehouse. While DecisionPoint had infrastructure components, the real value was in the type of data we provided, and how we structured that data for end users.
I will not judge what I thought were the good and bad points of each management regime. That is water under the bridge. However, the point to take away from this is the effect that regimes have on a startup. In each regime we had at DecisionPoint, they all came from the data warehousing industry, but each had a different focus within that industry. Because DecisionPoint products span many different aspects of the data warehousing industry, we had components of our product set that each regime understood really well and others they did not understand very well. Generally, each regime tended to focus on the components of the DecisionPoint products that they understood the best, rather than focusing on the overall DecisionPoint solution. This led to different sales and marketing positioning that each regime used even though the DecisionPoint product was the same across all regimes.
The good thing about regimes is that they bring valuable past experiences about what has worked for them successfully. However, the pitfall of the regime mentality is that you don’t think “out of the box” in many cases. Management regimes will often do what worked for them in the past, especially when it comes to sales and marketing. In many cases, what worked in the past does not apply to the current situation. Probably the most obvious example I have from DecisionPoint is in how our product was sold. The consistent theme across all management regimes at DecisionPoint (and is generally true in the high end software market) is to establish a high touch sales force goaled on selling a lot of software to large customers. Each regime thought that they would be the one to finally make the high touch sales model work better than the last one did. They each thought that if they worked at it a little harder (better sales reps, better training, etc.), they could crack the code for how to sell DecisionPoint products with a larger high touch sales force. None of them put any serious effort to completely rethink how the product should be sold. In the third management regime, we attempted a low end offering that would be ideal for middle and small market customers, but the sales force quickly rejected it. The bottom line is that if your sales force rejects it, they won’t sell it. Unfortunately, management at the time did not address the issue with the sales force, so the product offering died a slow, painful death.
The bottom line of the whole story and our different management regimes is that no matter what you do or who is involved, you have to be willing to try new and different things. Doing the same thing as you've done, unsuccessfully, before while working just a bit harder doesn't necessarily result in improvement. You always have to be willing to look at what you're doing, where you've been, and change course appropriately. Everyone brings valuable experience to a startup. However, if you only use that experience to do what you've done before, you're selling yourself and the startup short. Be bold, do something differently than it's ever been done before, and be confident that no matter what you do, you can adjust and move forward.
Thursday, June 3, 2010
A Newer Image Is Not Always Better...
In the last chapter, I spent a lot of time reviewing why newer is not always better from an engineering standpoint. However, I believe this also applies to all aspects of the business. The other two areas where you have to be very careful with this are in sales and marketing. Like engineers, sales and marketing people are very creative, but their creativity shows up in different ways than it does for engineers. Sales people are very creative in taking your product and making it look in the best possible light to potential customers. Marketing people are very creative in taking your product and wrapping it with just the right advertising and collateral whether it be web sites, magazine ads and stories, or brochures.
The biggest trap we fell into at DecisionPoint was having sales people convince us that if we built something, they would sell a lot of it. More often than not, the opposite was true. The phrase I remember almost every sales person saying to me was “if we just had X, I could sell more product”. So, we would go off and build X, and it would not help them sell our products any better than they had in the past. I spent more time at DecisionPoint building products that were never sold, also known as shelf-ware, than I ever anticipated I would build in my entire career in the software industry.
When you follow the needs of sales too closely, your product portfolio does increase. However, this also increases the amount of time, money, and people that you have to sustain to support the new product portfolio components. Rarely can you build and market something, and then just suddenly drop it. You have typically spent a lot of money not only in building the product, but also marketing the product. When you’ve spent that much money, which for a startup is significant, you don’t want to just throw the work away.
The other non-tangible side of this equation is the impact it has on morale. Generally, when engineers work on something, they work on it in hopes of seeing it used at a customer site to help the customer improve their business in some way. As an engineer, when you continue to build product that never gets sold, it gets demoralizing over time. You look at every new project with a great deal of suspicion as to whether it will ever see the light of day at a customer site. This, in turn, makes you approach every project very cautiously. And, while you would like to be able to think you would give it your best effort, you probably do not. It’s not to say that engineers become lazy, but after a while, they get gun shy wondering when the rug is going to be pulled out from under them next. Eventually, this leads to a huge rift between sales and engineering. Sales keeps asking for new things, and the logical engineering response is “you didn’t sell the last thing I built for you, what makes this any different?” Over time, it leads to engineers believing that sales people will never be able to sell what they build, and sales people believing that engineers never deliver what they truly need (which seems to change on an hourly basis).
On the other side of the coin, marketing lives in a world of “never good enough”. No matter how good your product is, and how well you market it, someone always seems to be doing it a lot better and faster than you can. I find that marketing departments will often have to “keep up with the Joneses.” While some of this will fall back to engineering in the form of product enhancements, most of these have more to do with how to better market the product that you have.
At one point in DecisionPoint’s history, we decided to completely re-brand the company and the company’s products. This included a new logo, a new company name, a new tag line, a new web site, new collateral, etc. All of it was in the guise of giving the company a new image. At the time, we were doing just fine as far as revenue goes. Customers were buying our products, and having a lot of success with them. However, no matter how much revenue you have, it could always be more. No matter how much collateral you have it could always be better. Looking back at it, we got too caught up in comparing ourselves to other companies rather than just continuing to do what we were already doing well. You do want to keep an eye on what the competition is doing, but you should use that as just one data point when it comes to your marketing strategy. Too often in the software world, companies are too focused on comparing themselves to the competition rather than emphasizing what they do well independent of any comparisons.
Probably the best way to tell the marketing story and lessons learned is to go through the different logos and company names that we went through at DecisionPoint. While all of them represented change in the company, none of it fundamentally made a difference in our ability to sell our software to customers. As you will see through the various examples, the names changed, but the core value of the product stayed the same. Describing the same thing differently with a new fresh face doesn’t always mean that you will be better at selling your product.
The above logo represents the first branding of our products and the company. This particular logo has an interesting heritage. The “cat scratch circle” as it has been referred to was actually inherited from Sequent. Prior to the spin-off of DecisionPoint, Sequent re-branded a data warehouse database product called Redbrick, which was later bought by Informix, which later was bought by IBM. Sequent’s version of Redbrick was known as DecisionPoint, and the “cat scratch circle” was the logo. By the time that DecisionPoint was spun out of Sequent, the re-branded Redbrick product was no longer being sold. So, since all of the logos and trademarks were already owned by Sequent, we decided to inherit the name and the logo. When we were spun out of Sequent, we discovered that the name DecisionPoint was already being used in other countries. So, we formally registered as DP Applications, Inc. but doing business as DecisionPoint. This is also when we developed our first tag line “decision making by the numbers”. In usual startup fashion, the company name, logo, and tag line were all “free” so they came at a very good price.
The second variation of the logo was also fairly cheap. We added some color to the “cat scratch circle”, and made the letters appear more dynamic and aggressive. Again, the cost was right as it was all work that we could do internally without spending money.
The logo above was the first time we spent significant money re-branding the company. At that time, we had a marketing manager, and had just received a large influx of cash from our investors. Our marketing manager decided that it was time for a new image. We spent a lot of money with a firm to come up with a new logo, and new way to show the company name, a new tag line, along with all the usual types of collateral like a web site, brochures, stationary, envelopes, etc. The logo actually was from a picture of a light shining through a crack in a cavern illuminating a spot on the cavern floor. The logo color didn’t have an official name, but was referred to by its Pantone Matching System number, which is owned by PANTONE, INC. The number was PMS 384 or PMS 386. I can’t remember which it was, but the color didn’t even have a name. The grey shape at the bottom of the logo was actually gold in color. The theme was that our software provided the light that shown through the darkness to help you find the pot of gold in your financial information.
At the time, this investment seemed like the right thing to do. We had received a fresh round of cash from investors, so it seemed like a good investment of money. As stated many times before, the investment really wasn’t justified by the return we received on that investment. In addition, the original tag line that the agency found for us was “Now You Know”. Only after everything was done did we discover that it was already being used by another company, and that’s when we defaulted to using “Uncommon Insight”.
The logo above represents what you do when you want to try and define a new market for your software. Each time we had a new management team come into the company, they always were looking for a way to re-brand the company that would draw attention from potential customers. Also, as stated previously in this book/blog, marketing folks are always trying to catch the attention of industry analysts by defining a new sector within an existing market. The structure of the logo changed, but more importantly, we changed the tag line. Up until this point, decision support software was largely defined as passive, which means show me what happened. We were trying to define a new market to make decision support more active. This meant that it would retain its current passive nature, but would also help in molding how you ran your business in the future with analysis based on prediction. In other words, the ability of people to perform the analysis of data to predict future events in the business. Unfortunately, this lead to the “double whammy”. We didn’t attract any more attention from industry analysts, and we didn’t attract new customers with this new concept. I think one of the most important lessons learned from this experience was that it is very hard for a small company to define a new market. Because you are small, and only have a few customers, you don’t have the clout to define a new market. However, larger companies with larger customer bases can define new markets fairly easily.
The last two logos were the ones used by the final management team before we were acquired. At first, we went back to the basic logo with no tag line. Then, it was decided that the word Applications had a somewhat negative connotation in the software industry. So, we switched to the DecisionPoint Software name. Once again, new web site, new brochures, new stationary, new collateral, etc. But, once again, little return on investment in this area.
Overall, the lesson learned for me when it came to marketing was that you need to be clean, but you don’t need to be great. Fancy logos and tag lines aren’t what sells your product to customers. The people within your company, and their ability to convince customers that they need your software is really what is important. Potential customers may go to your web site to get information, but at the end of the day, they buy software from people they trust, and people that can convince them the software will make a difference in their company’s success. No amount of fancy logos and pictures can replace the face to face contact that gives a customer a comfort level that they are buying a good software product from a quality team of people.
The biggest trap we fell into at DecisionPoint was having sales people convince us that if we built something, they would sell a lot of it. More often than not, the opposite was true. The phrase I remember almost every sales person saying to me was “if we just had X, I could sell more product”. So, we would go off and build X, and it would not help them sell our products any better than they had in the past. I spent more time at DecisionPoint building products that were never sold, also known as shelf-ware, than I ever anticipated I would build in my entire career in the software industry.
When you follow the needs of sales too closely, your product portfolio does increase. However, this also increases the amount of time, money, and people that you have to sustain to support the new product portfolio components. Rarely can you build and market something, and then just suddenly drop it. You have typically spent a lot of money not only in building the product, but also marketing the product. When you’ve spent that much money, which for a startup is significant, you don’t want to just throw the work away.
The other non-tangible side of this equation is the impact it has on morale. Generally, when engineers work on something, they work on it in hopes of seeing it used at a customer site to help the customer improve their business in some way. As an engineer, when you continue to build product that never gets sold, it gets demoralizing over time. You look at every new project with a great deal of suspicion as to whether it will ever see the light of day at a customer site. This, in turn, makes you approach every project very cautiously. And, while you would like to be able to think you would give it your best effort, you probably do not. It’s not to say that engineers become lazy, but after a while, they get gun shy wondering when the rug is going to be pulled out from under them next. Eventually, this leads to a huge rift between sales and engineering. Sales keeps asking for new things, and the logical engineering response is “you didn’t sell the last thing I built for you, what makes this any different?” Over time, it leads to engineers believing that sales people will never be able to sell what they build, and sales people believing that engineers never deliver what they truly need (which seems to change on an hourly basis).
On the other side of the coin, marketing lives in a world of “never good enough”. No matter how good your product is, and how well you market it, someone always seems to be doing it a lot better and faster than you can. I find that marketing departments will often have to “keep up with the Joneses.” While some of this will fall back to engineering in the form of product enhancements, most of these have more to do with how to better market the product that you have.
At one point in DecisionPoint’s history, we decided to completely re-brand the company and the company’s products. This included a new logo, a new company name, a new tag line, a new web site, new collateral, etc. All of it was in the guise of giving the company a new image. At the time, we were doing just fine as far as revenue goes. Customers were buying our products, and having a lot of success with them. However, no matter how much revenue you have, it could always be more. No matter how much collateral you have it could always be better. Looking back at it, we got too caught up in comparing ourselves to other companies rather than just continuing to do what we were already doing well. You do want to keep an eye on what the competition is doing, but you should use that as just one data point when it comes to your marketing strategy. Too often in the software world, companies are too focused on comparing themselves to the competition rather than emphasizing what they do well independent of any comparisons.
Probably the best way to tell the marketing story and lessons learned is to go through the different logos and company names that we went through at DecisionPoint. While all of them represented change in the company, none of it fundamentally made a difference in our ability to sell our software to customers. As you will see through the various examples, the names changed, but the core value of the product stayed the same. Describing the same thing differently with a new fresh face doesn’t always mean that you will be better at selling your product.
The above logo represents the first branding of our products and the company. This particular logo has an interesting heritage. The “cat scratch circle” as it has been referred to was actually inherited from Sequent. Prior to the spin-off of DecisionPoint, Sequent re-branded a data warehouse database product called Redbrick, which was later bought by Informix, which later was bought by IBM. Sequent’s version of Redbrick was known as DecisionPoint, and the “cat scratch circle” was the logo. By the time that DecisionPoint was spun out of Sequent, the re-branded Redbrick product was no longer being sold. So, since all of the logos and trademarks were already owned by Sequent, we decided to inherit the name and the logo. When we were spun out of Sequent, we discovered that the name DecisionPoint was already being used in other countries. So, we formally registered as DP Applications, Inc. but doing business as DecisionPoint. This is also when we developed our first tag line “decision making by the numbers”. In usual startup fashion, the company name, logo, and tag line were all “free” so they came at a very good price.
The second variation of the logo was also fairly cheap. We added some color to the “cat scratch circle”, and made the letters appear more dynamic and aggressive. Again, the cost was right as it was all work that we could do internally without spending money.
The logo above was the first time we spent significant money re-branding the company. At that time, we had a marketing manager, and had just received a large influx of cash from our investors. Our marketing manager decided that it was time for a new image. We spent a lot of money with a firm to come up with a new logo, and new way to show the company name, a new tag line, along with all the usual types of collateral like a web site, brochures, stationary, envelopes, etc. The logo actually was from a picture of a light shining through a crack in a cavern illuminating a spot on the cavern floor. The logo color didn’t have an official name, but was referred to by its Pantone Matching System number, which is owned by PANTONE, INC. The number was PMS 384 or PMS 386. I can’t remember which it was, but the color didn’t even have a name. The grey shape at the bottom of the logo was actually gold in color. The theme was that our software provided the light that shown through the darkness to help you find the pot of gold in your financial information.
At the time, this investment seemed like the right thing to do. We had received a fresh round of cash from investors, so it seemed like a good investment of money. As stated many times before, the investment really wasn’t justified by the return we received on that investment. In addition, the original tag line that the agency found for us was “Now You Know”. Only after everything was done did we discover that it was already being used by another company, and that’s when we defaulted to using “Uncommon Insight”.
The logo above represents what you do when you want to try and define a new market for your software. Each time we had a new management team come into the company, they always were looking for a way to re-brand the company that would draw attention from potential customers. Also, as stated previously in this book/blog, marketing folks are always trying to catch the attention of industry analysts by defining a new sector within an existing market. The structure of the logo changed, but more importantly, we changed the tag line. Up until this point, decision support software was largely defined as passive, which means show me what happened. We were trying to define a new market to make decision support more active. This meant that it would retain its current passive nature, but would also help in molding how you ran your business in the future with analysis based on prediction. In other words, the ability of people to perform the analysis of data to predict future events in the business. Unfortunately, this lead to the “double whammy”. We didn’t attract any more attention from industry analysts, and we didn’t attract new customers with this new concept. I think one of the most important lessons learned from this experience was that it is very hard for a small company to define a new market. Because you are small, and only have a few customers, you don’t have the clout to define a new market. However, larger companies with larger customer bases can define new markets fairly easily.
The last two logos were the ones used by the final management team before we were acquired. At first, we went back to the basic logo with no tag line. Then, it was decided that the word Applications had a somewhat negative connotation in the software industry. So, we switched to the DecisionPoint Software name. Once again, new web site, new brochures, new stationary, new collateral, etc. But, once again, little return on investment in this area.
Overall, the lesson learned for me when it came to marketing was that you need to be clean, but you don’t need to be great. Fancy logos and tag lines aren’t what sells your product to customers. The people within your company, and their ability to convince customers that they need your software is really what is important. Potential customers may go to your web site to get information, but at the end of the day, they buy software from people they trust, and people that can convince them the software will make a difference in their company’s success. No amount of fancy logos and pictures can replace the face to face contact that gives a customer a comfort level that they are buying a good software product from a quality team of people.
Wednesday, June 2, 2010
Stay Focused
Generally, startup companies attract very talented and motivated individuals. They often join the startup with the hope that they can help mold and shape the company with their thoughts and ideas. Unlike larger companies, individuals thrive off of the possibility that they would have a chance to greatly influence the direction of the products of the startup. However, if not properly managed, the startup can suffer from “idea overload”.
When the products are in the early phases of development, there are many thoughts and ideas on the multitude of possibilities the direction that the products could take. Creative people often are very passionate about their ideas, and will hold strong opinions when it comes to products and product direction. This creates a natural tension in product development. You want the best ideas, but you also have to know that you can’t take all of the ideas. You have to draw a line somewhere in order to meet your objectives. This is especially true in the computer software world. There are many options and opinions on the best way to accomplish something. In many cases, there really isn’t a “wrong” way to do something as long as it works.
At DecisionPoint, we faced several challenges when it came to introducing new products, and upgrading existing technology. Some of the decisions that were made greatly benefited new and improved products, and other decisions did not. Unfortunately, hindsight is always 20/20, and I probably wouldn’t have made the same decisions now as I did then. A lot of it had to do with my inability to properly gauge what was best for the product and company, while at the same time, keeping engineers refreshed and motivated. Motivated engineers are an invaluable resource, and you do your best to keep them happy. That was my primary focus as I looked at the best way to carry our products forward. However, I should have spent more time trying to balance what was right with what was motivating.
Our largest hurdle was probably the first time we were productizing the original work that I had done within Sequent. We were given six months to finish the productization, so there was little time for deliberation and debate about what was best. Given the short timeframes we had to deliver product, we had to take several shortcuts. The original code that was written was built in C, and hardwired for Sequent’s implementation of Oracle Applications. Oracle Applications is highly configurable, so the code that was written would not easily plug into another customer site without modifications. Additionally, it was C code, so the modifications that needed to be made were not able to be done easily by the customer. To make the solution easier to implement, we continued to work in C, but we added integration with database technology to support the configurability aspects of Oracle Applications. One set of C programs could read the customer’s configuration of Oracle Applications into a database, and another set of C programs could read the information in the database, and then dynamically re-configure themselves to fit the customer’s environment. The code worked well enough, but was very difficult to install, and required quite a bit of expertise to install properly. Looking back, we should have taken the time needed to polish the code to make it more installable and supportable versus strictly worrying about time to market requirements.
In our second release, we made significant strides in improving the code from the first release. We used more robust development environments, and built a nice user interface on top of all of the programs, and made the software much easier to install and support. While the product still provided the same fundamental value to the end users at the customer site, we finally were able to overcome the technical issues that were our Achilles heel in the first release.
Our third release was probably the first really big mistake that I made in selecting technologies to leverage for our development. Our second release had user interfaces built in Visual Basic, which was very easy for the engineers to use in building software. It did have limitations, but from a customer perspective, the technology that we were using was not an issue. Our engineers desperately wanted to start learning new tools and technology. They pushed very hard to switch from Visual Basic to C++ claiming that they could be much more productive in that development environment. The problem was that none of them had experience developing in C++, and the technology itself was not only a technical change, but also required changes in the way that code was developed.
We assumed that we could send the engineers to training classes, and that all would be well. The mistake that I made was underestimating how long it would take the engineers to come up to speed not only on the technology piece, but also on the change that was required in the development approach. With no experienced engineer in the new technology, we proceeded forward. We managed to be able to build product with the new software development tools, but we made many rookie mistakes that could have been avoided if we either stuck to what we already knew, or if we brought on a senior engineer with experience in the new environment. We missed our schedule for that release, and as we learned later on in the company’s history, we also built an environment that was very difficult for new engineers to pick up and learn when we hired them onto the engineering team. At that point, I learned a very painful lesson that I would come to regret many times in the following years. We set ourselves up so that making even the simplest changes to our software was a long, tedious, and difficult process. While the older Visual Basic technology was “behind the times” as far as engineers were concerned, we probably should have delayed the switch until after we had more experienced engineers in that area.
A couple of years later, we would make a similar mistake in a different area. Up until this point in the company’s history, our strength had been more on what is known as the infrastructure components. Our software would virtually run itself after installed. The challenge was that when you present that type of software to customers, it’s like having them watch a submarine race. There’s not much to show or see.
About this time, we had a change in management. The new management team didn’t have a lot of experience in our core strength, which was getting data out of Oracle Applications into a usable format. Their experience was deep in building tools that allowed end users to easily browse and navigate data. In order to expand our market share and visibility with a broader audience, we decided to put together a series of complex tools that allowed finance personnel to easily browse and navigate the data. It was radically different than anything we had done before. The new management team decided that it would be best to take some of the senior engineers, isolate them to work on this new project, and have them develop the new product without any technical boundaries or guidelines. The engineers responsible for the project decided that the user interfaces would be built in Microsoft .NET and C#, and the server code would be written in java services using XML as a storage mechanism. All of the technologies were fairly new and relatively unknown. While the work that they did resulted in a very good product, we suddenly had a development environment that was different than our previous development environments, and also an environment that it was difficult to find additional engineers to develop with.
Some could argue that the switch in technologies was a good one as it gave us capabilities that we could not get in the existing technologies we were using. However, the resulting product was typical of what you get when you isolate very talented and creative engineers with no guidelines or boundaries. In many ways, we tied our own hands. The software that was built with the older technologies was solid, but very difficult to change. The software built with the new technologies was less solid even though it still worked, but we could not easily find engineers that could readily develop in that environment. Again, the lesson learned is that new technology for technology’s sake is not necessarily a good reason to change your entire engineering environment.
Since the completion of the previously mentioned products, we have spent the last couple of years unwinding the two sets of technologies and combining them into one. We have migrated the older technologies to the java environment, but have done it in a way that is more reasonable. Additionally, we have been unwinding the complexities of the existing java environment to make them simpler, and to cut down the product features that weren’t being actively used by the customer. Unfortunately, there is a tremendous amount of code and complexity that it will continue to take us months and years of work to get everything on the same technology platforms.
When it comes to engineering, you have to picture everything as a pay me now or pay me later proposition. Every time you decide to make a major technology shift, you have to do so in a manner that makes sense. Going to bleeding edge technology every chance you get will often create a deficit situation for you. It may work, but sustaining the code, and finding engineers to support the code that have the appropriate level of experience will be difficult. Additionally, when you are introducing brand new pieces of technology, you have to have a plan as to how you intend to move the older technology forward. You can’t simply ignore it and hope it goes away some day. Probably the two highest recommendations I can make in this area are to create and follow a manageable product roadmap, and have frequent technology reviews to ensure that everything being done fits in the overall strategy of the product roadmap. Engineers are very bright and creative people that can come up with amazing ways to solve technology problems. However, this has to be balanced with what is reasonable and makes sense from a product development standpoint.
When the products are in the early phases of development, there are many thoughts and ideas on the multitude of possibilities the direction that the products could take. Creative people often are very passionate about their ideas, and will hold strong opinions when it comes to products and product direction. This creates a natural tension in product development. You want the best ideas, but you also have to know that you can’t take all of the ideas. You have to draw a line somewhere in order to meet your objectives. This is especially true in the computer software world. There are many options and opinions on the best way to accomplish something. In many cases, there really isn’t a “wrong” way to do something as long as it works.
At DecisionPoint, we faced several challenges when it came to introducing new products, and upgrading existing technology. Some of the decisions that were made greatly benefited new and improved products, and other decisions did not. Unfortunately, hindsight is always 20/20, and I probably wouldn’t have made the same decisions now as I did then. A lot of it had to do with my inability to properly gauge what was best for the product and company, while at the same time, keeping engineers refreshed and motivated. Motivated engineers are an invaluable resource, and you do your best to keep them happy. That was my primary focus as I looked at the best way to carry our products forward. However, I should have spent more time trying to balance what was right with what was motivating.
Our largest hurdle was probably the first time we were productizing the original work that I had done within Sequent. We were given six months to finish the productization, so there was little time for deliberation and debate about what was best. Given the short timeframes we had to deliver product, we had to take several shortcuts. The original code that was written was built in C, and hardwired for Sequent’s implementation of Oracle Applications. Oracle Applications is highly configurable, so the code that was written would not easily plug into another customer site without modifications. Additionally, it was C code, so the modifications that needed to be made were not able to be done easily by the customer. To make the solution easier to implement, we continued to work in C, but we added integration with database technology to support the configurability aspects of Oracle Applications. One set of C programs could read the customer’s configuration of Oracle Applications into a database, and another set of C programs could read the information in the database, and then dynamically re-configure themselves to fit the customer’s environment. The code worked well enough, but was very difficult to install, and required quite a bit of expertise to install properly. Looking back, we should have taken the time needed to polish the code to make it more installable and supportable versus strictly worrying about time to market requirements.
In our second release, we made significant strides in improving the code from the first release. We used more robust development environments, and built a nice user interface on top of all of the programs, and made the software much easier to install and support. While the product still provided the same fundamental value to the end users at the customer site, we finally were able to overcome the technical issues that were our Achilles heel in the first release.
Our third release was probably the first really big mistake that I made in selecting technologies to leverage for our development. Our second release had user interfaces built in Visual Basic, which was very easy for the engineers to use in building software. It did have limitations, but from a customer perspective, the technology that we were using was not an issue. Our engineers desperately wanted to start learning new tools and technology. They pushed very hard to switch from Visual Basic to C++ claiming that they could be much more productive in that development environment. The problem was that none of them had experience developing in C++, and the technology itself was not only a technical change, but also required changes in the way that code was developed.
We assumed that we could send the engineers to training classes, and that all would be well. The mistake that I made was underestimating how long it would take the engineers to come up to speed not only on the technology piece, but also on the change that was required in the development approach. With no experienced engineer in the new technology, we proceeded forward. We managed to be able to build product with the new software development tools, but we made many rookie mistakes that could have been avoided if we either stuck to what we already knew, or if we brought on a senior engineer with experience in the new environment. We missed our schedule for that release, and as we learned later on in the company’s history, we also built an environment that was very difficult for new engineers to pick up and learn when we hired them onto the engineering team. At that point, I learned a very painful lesson that I would come to regret many times in the following years. We set ourselves up so that making even the simplest changes to our software was a long, tedious, and difficult process. While the older Visual Basic technology was “behind the times” as far as engineers were concerned, we probably should have delayed the switch until after we had more experienced engineers in that area.
A couple of years later, we would make a similar mistake in a different area. Up until this point in the company’s history, our strength had been more on what is known as the infrastructure components. Our software would virtually run itself after installed. The challenge was that when you present that type of software to customers, it’s like having them watch a submarine race. There’s not much to show or see.
About this time, we had a change in management. The new management team didn’t have a lot of experience in our core strength, which was getting data out of Oracle Applications into a usable format. Their experience was deep in building tools that allowed end users to easily browse and navigate data. In order to expand our market share and visibility with a broader audience, we decided to put together a series of complex tools that allowed finance personnel to easily browse and navigate the data. It was radically different than anything we had done before. The new management team decided that it would be best to take some of the senior engineers, isolate them to work on this new project, and have them develop the new product without any technical boundaries or guidelines. The engineers responsible for the project decided that the user interfaces would be built in Microsoft .NET and C#, and the server code would be written in java services using XML as a storage mechanism. All of the technologies were fairly new and relatively unknown. While the work that they did resulted in a very good product, we suddenly had a development environment that was different than our previous development environments, and also an environment that it was difficult to find additional engineers to develop with.
Some could argue that the switch in technologies was a good one as it gave us capabilities that we could not get in the existing technologies we were using. However, the resulting product was typical of what you get when you isolate very talented and creative engineers with no guidelines or boundaries. In many ways, we tied our own hands. The software that was built with the older technologies was solid, but very difficult to change. The software built with the new technologies was less solid even though it still worked, but we could not easily find engineers that could readily develop in that environment. Again, the lesson learned is that new technology for technology’s sake is not necessarily a good reason to change your entire engineering environment.
Since the completion of the previously mentioned products, we have spent the last couple of years unwinding the two sets of technologies and combining them into one. We have migrated the older technologies to the java environment, but have done it in a way that is more reasonable. Additionally, we have been unwinding the complexities of the existing java environment to make them simpler, and to cut down the product features that weren’t being actively used by the customer. Unfortunately, there is a tremendous amount of code and complexity that it will continue to take us months and years of work to get everything on the same technology platforms.
When it comes to engineering, you have to picture everything as a pay me now or pay me later proposition. Every time you decide to make a major technology shift, you have to do so in a manner that makes sense. Going to bleeding edge technology every chance you get will often create a deficit situation for you. It may work, but sustaining the code, and finding engineers to support the code that have the appropriate level of experience will be difficult. Additionally, when you are introducing brand new pieces of technology, you have to have a plan as to how you intend to move the older technology forward. You can’t simply ignore it and hope it goes away some day. Probably the two highest recommendations I can make in this area are to create and follow a manageable product roadmap, and have frequent technology reviews to ensure that everything being done fits in the overall strategy of the product roadmap. Engineers are very bright and creative people that can come up with amazing ways to solve technology problems. However, this has to be balanced with what is reasonable and makes sense from a product development standpoint.
Subscribe to:
Posts (Atom)
Visitors
