Bridging the gap to Fusion through our PeopleSoft Solutions Extenders
Grey Sparling PeopleSoft Expert's Corner
Oracle Blogs
 Subscribe Now!

Thursday, July 26, 2007

The Good, Bad, and Ugly of our Niche... Part 3

This is the final posting in our series that analyzes the niche that Grey Sparling Solutions has gone after. The first posting already looked at the niche itself. Now that we've looked at how our business plan has affected our execution on our corporate strategy, marketing, and sales, it's time to look at engineering, support and administration.

Engineering
As you can imagine, engineering and development is one of those areas that hasn't been as much of an issue for us (coming from the development ranks inside PeopleSoft). Probably the biggest thing that's caused us issues on the engineering side is PeopleTools bugs and other PeopleTools limitations (yes, I'm sure there are several former and current PeopleSoft application developers who are laughing at the irony of that statement). Here are some things that we have done internally on the engineering side.

  • We've built several internal tools to help us develop more efficiently, including version control for PeopleTools (which we're in the process of productizing).

  • We've focused a lot of engineering on simplifying the installation process of our products within a PeopleSoft environment.

  • We focused a lot of engineering on allowing us to provide trial versions that allow customers to try out all features of the product, where the product will stop working after the trial period extends (when the customer purchases the product, they merely need to put in a new license key without having to re-install the product).

  • Finally, in the past 2 years, we've released 3 major revisions of 2 products and released 5 other products. We also have 2 new products currently under development.
As you can see, we've done a lot with a reasonably small development staff in a very short period of time.

For those who are interested in some of the software products we use internally (for either running our own processes or development), here's a list of some of them:

  • VMWare. We use this extensively to help us maximize individual productivity in development, testing, and support. We even have thoughts of building out some VMWare appliances with our software on it, but haven't due to licensing risks for the middleware PeopleSoft needs.

  • Email and Website Hosting. We use Yahoo Small Business. Although we could have done this ourselves, we'd prefer to have somebody else ensure that we have 24x7 availability of our website and email. We also don't have to worry about bandwidth (because there are times when we have lots of folks watching our flash demos at the same time). In case you were wondering, we did the website ourselves using HTML-Kit.

  • Web Conferencing. Originally, we used Copilot for all support activities and either Microsoft Live Meeting or Webex for formal presentations. Eventually, we realized that we were paying more to Microsoft or Webex than for telephone, internet, and web/email hosting combined. Our friends at MiPro consulting pointed us to GoToMeeting (a Citrix product), which costs about 15% of what we were paying previously for this. If we didn't need to do marketing presentations and demos, we probably would have just used Copilot, because it's even less expensive for 1-on-1 assistance (support).

  • SugarCRM [Open Source]. We use SugarCRM for all of our contact management and CRM activities (running on MySQL, of course).

  • Subversion and Trac [Open Source]. We get a lot of mileage out of both of these products.
    • Subversion is a nice plug-in to windows explorer that helps us version any document that's important to us. This includes our PeopleTools objects, legal documents, marketing documents, demo objects, etc.

    • Trac is a web front-end to the subversion repository that also includes a WIKI, and ticket tracking. We've been bailed out a few times at customer sites where we could access either the source or download compiled objects.

  • Browser troubleshooting. This probably falls under the "Support" topic below, but I figured since I was listing products we use, that FiddlerTool should be in the list as well. This helps us diagnose what's going on from a browser perspetive. If you're getting wierd problems with your application, FiddlerTool is a great place to start, because it logs everything that's going on in the browser.

  • Image Capture and Flash Demo Recording. We use Snagit and Camtasia for both of these. For recording demos, we tried to use an extra license of Pinnacle Studio that I had for working on family videos. Unfortunately, the screenshots ended up getting fuzzy as I tried to work with them. Camtasia makes it pretty easy to record powerpoints and your demos as well as providing the editing and publishing functions in 1 place. For the number of flash demos we record, it's been worth it.

  • Website Analysis. We ended up building our own solution that allows us to perform analysis on our web traffic. Because our analysis is pretty simple and straightforward, I ended up writing what I needed in VBA and Excel.

  • Phone Service. Our business phones are exclusively VOIP (Vonage for home access, and another service for our main line... no, not Skype, although our friends at Workday swear by it). We're in the process of implementing the Asterisk PBX solution to provide a more robust experience that what we currently have (which almost always forwards the business line to me). Because Vonage is set up so that products like Asterisk won't work with it, we use a different service for our main PBX line. We've already played around with using it to allow us to dial internationally from the VOIP and using our cell phone to access it (which we sometimes want to do when we're on the road... we actually used it when we were at collaborate).

  • One other project in this vein that we're working on is building a more robust extranet than what we currently have (we're finding that now that we're about to go above 20 active customers, it will be nice to provide additional tools to help them collaborate with respect to our products.

Support
On the support side, we've incorporated a lot of functionality into our products that facilitate supporting them. As mentioned previously, we've intentionally incented ourselves to make our products easy to install and support as part of our business model. As such, we have the following in our products to facilitate support:
  • PeopleSoft Diagnostics. We've embedded our own diagnostics tool into our products to make it easy to proactively find configuration issues, setup issues, and issues related to dependencies to PeopleSoft data (such as valid users, email addresses, etc).

  • Advanced Logging. We've spent a lot of time and energy in ensuring that robust logs are generated from our products that give us exactly the information we need to troubleshoot issues.

  • Setup and Configuration Utilities. We've built installers to help install and configure client code (such as PSIDE Helper and GS Excel Add-in). In addition, we have utilities we've built to set up the navigation and permissions for objects included in our products to simplify setup.


Administration
Administration encompasses Legal, Accounting, and Payroll. We'll start with the Accounting and Payroll functions, because they've been pretty painless for us.

On the Accounting side, we've been able to optimize our operations so that we spend only a few hours a week dealing with bookkeeping. As with many other things, we'd prefer to spend our limited resources developing wherever possible, which means that Brian and myself split up doing the bookkeeping. Because Brian developed much of the infrastructure for NetSuite (including the payroll module), and I was one of the first Financial consultants at PeopleSoft, we're more than happy to do this. Filling out the different regulatory forms isn't as much fun, but I'm more than happy to do it when we need to. So far, it seems to be working, because our CPA bills have been extremely reasonable.

On the Payroll side, we're small enough that we can do most of the calculations in excel (did I mention that Brian wrote Netsuite's payroll module?). We have our CPAs do our quarterly payroll tax returns, which, again is extremely reasonable in price.

Legal
The last topic in this section is Legal. This has been one of the areas that we've really had to watch. We decided to retain one of the top Intellectual Property firms in the country to help us protect our assets. These guys watch out for Sun Microsystem's intellectual property among other things.

Obviously, the first thing we needed to do was to make sure that we could legally productize PeopleSoft bolt-ons and not get into any Intellectual Property issues. This was actually easier than we thought, but did take some effort and a bit of our start-up money. The second thing we needed to do was to come up with our own paper for our license agreements and NDAs. This took a few revisions, because we wanted to make sure that (1) our IP was protected, and (2) that we didn't get dragged into a lawsuit in the event that a customer dropped support from Oracle.

This has gone pretty well for us with the exception of working with a few prospective customers, who have overzealous legal departments. I think a lot of this has to do with the fact that we're different than most organizations those prospective customers work with.
  • We're a lot smaller than our customers are and don't have a large warchest of funds earmarked for litigation. What this means is that these organizations are much better funded for any court action.

  • We're a software company with intellectual property that we have to protect. Many organizations that do what we do are consulting firms, where the knowledge in somebody's head is much of what they sell (and is something that can't easily be taken away in the event that the company goes under). By contast, we spent quite a lot of time building up our products, which are assets that somebody can take away.

  • Our products are enterprise products, which means that they're installed on servers and deployed widely. This means that we can't avoid doing license agreements because of the protections needed on both sides (we've spent a lot of time looking at click-through license agreements to streamline the process, but unfortunately, they don't find the protection we need)

Therefore, we need to protect ourselves in a way that we can enforce our agreements and not run out of money doing so. This means that every one of our license agreements have language that states that the the winning party is entitled to recover their attorneys fees from the other party.

Because most organizations enter into business with us with good faith, and the attorneys fees clause only gets invoked in the event that the customer is found in breach of contract; this language is usually not an issue. Unfortunately, we've had a couple of prospective customers where we had to walk away from them because they would not agree to this language. In both of these circumstances, they had very large purchasing and/or legal departments (they either buy millions of napkins, or memory chips; or their business requires them to enter into contracts with most of their customers). Because these organizations essentially wanted to rewrite our license agreement and this was the deal-breaking issue, in both circumstances, we ended up paying out a lot of money to our external counsel to review their proposed changes and negotiate in good faith. It was a shame, because the folks who wanted to use the product had gotten the budget approved, the product installed, were ready to move it into production, and just needed to get the license agreement signed (and we really liked working with those folks).

Summary
Well, if you read all of this, I congratulate you. These 3 postings are much longer than I anticipated and probably provide much more detail than would interest most people. Of course, I thought that was the case with our Business Units and Setids blog posting, and it's still one of the more popular ones on the site.

Labels:

Monday, July 23, 2007

The Good, Bad, and Ugly of our Niche... Part 2

This is the second posting in our series that analyzes the niche that Grey Sparling Solutions has gone after. The first posting already looked at the niche itself. Now that we've ascertained that Grey Sparling Solutions is a products company, focused on PeopleSoft, selling to other businesses (large organizations); let's look at how that affects our corporate strategy, sales, and marketing.

The Market Opportunity
When we started Grey Sparling Solutions, we believed strongly that PeopleSoft customers would be staying on their PeopleSoft applications for quite a while, and that there was a lot of pent up demand for new technical functionality. We also realized that customers did not want to move from their existing PeopleSoft products, due to the cost of doing so.

What we didn't know was whether PeopleSoft customers would "batten down the hatches" with their PeopleSoft applications with Fusion on the horizon. With this concern in mind, we included in our business plan strategies to make sure that customers could measure the ROI of our products in weeks, not months.

What we found is that PeopleSoft customers are willing to spend money on their ERP systems, and that there is, indeed, a solid market for PeopleSoft bolt-ons.

Marketing
The next area is Marketing. Because we are selling to large organizations, it's imperative that they know who we are and what we represent. Being self-funded, we also recognized that every dollar we spend in marketing is one less dollar we have for engineering and other things.

Our marketing strategy is pretty simple (and is used very successfully by many Business-to-Consumer organizations). Instead of putting together fancy advertisements, a flashy website, and spending money on all the other things that organizations spend money on to get attention, we focus on viral marketing. Therefore, our marketing is focused on the following areas:
  • Our Blog. By putting out tips and techniques that help people get their jobs done, there are a lot of organizations who know about us, and see that we know our stuff.
  • User group meetings. Because we used to give the PeopleTools sessions at various PeopleSoft conferences, we've been asked to give similar presentations at user group meetings. Because we're often asked as PeopleSoft experts and not as vendors, our presentations almost never discuss our products, which is something a lot of organizations aren't willing to do. It is our belief that if we provide good enough content, people will look us up after the user group meetings (or talk with us there).
  • Swagware. This is a term we coined to represent our marketing give-aways. Instead of providing give-aways that have nothing to do with who we represent (such as mugs, pens, etc.), we provide licenses to product that solve specific problems for PeopleSoft customers.
By all measurable accounts, these techniques have been working well for us. PeopleSoft customers definitely know who we are, based on the various techniques we use to measure this (website traffic, number of self-referred prospects, 3rd party referrals, and contact list).

That said, we've also found (and we'll cover this in more detail in the sales setion) that although the folks who work with PeopleSoft know us very well, many of the higher level decision makers, aren't that familiar with us (which isn't surprising, given the places we've focused). Often, this means that we're dependent on the people internally who run the PeopleSoft applications to educate their management as to who we are when it gets to a certain point in the sales process.

Sales
The last topic of today's posting is sales. As I mentioned in the first posting of this series, we've made a conscious decision to avoid hiring dedicated sales people where all they do is sales. This is probably the one decision that we spend the most time discussing and revisiting (especially when we see large opportunities on the horizon that require a lot of effort to work the sales process). Here are the main reasons why we haven't done this yet:
  • We want to ensure that our corporate identity as the PeopleTools experts is reinforced with every communication we have with an organization. Most of the best salespeople we know are great at building relationships, identifying the decision-making process in a company, and working the process to get a deal closed. This is why many sales organizations have the relationship people and the product people (my first view into this was at IBM, where my father was a Systems Engineer (SE), and he was lined up with a Sales Manager... my Dad knew the products, and the sales manager knew how to sell).
  • We want to manage our growth carefully. Being near Silicon Valley, we have lots of colleagues (many of the former PeopleSoft-ers) who ended up having excellent salespeople who ended up bringing in more new customers than the organization could support. This caused all sorts of issues with those companies because the company usually didn't have time to build a sufficient infrastructure internally to support all these new customers. We didn't want to fall into this trap, and Chris has been instrumental in helping us get the infrastructure in place that we need for growing the business successfully.
  • We wanted to make sure that we always followed through on our commitments to customers. One of the best ways to ensure this is to keep the person doing the selling involved in the delivery and/or support of that product. If you have to make a customer successful on what you're selling to him, you'll make sure that you can deliver on what you promise.
Although we think this is the right thing for use to do, we've also had enough times where we've been tripped up in the sales process due to this decision. When your sales team has other responsibilities, it's easy to get immersed in activites and miss a sales opportunity because you weren't at right place at the right time. In addition, many large organizations are set up to buy from organizations with large sales teams who can dedicate lots of time to each and every deal. Quite often, this means spending a lot of time providing lots of information to help justify the decision, but it also means ensuring that the price of the product reflects the additional cost of sales. We've put lots of things in place on our end to help streamline the process.
  • We provide a lot of detailed information about our products on the website. Although this is something that few organizations do because of concerns of theft of intellectual property, we decided that the benefits outweigh the risks (and in the end, we believe that even if somebody tries to match us feature for feature, that our expertise with PeopleSoft means that our product would beat one that somebody tries to copy).
  • We record and provide demos of each of our products on our website. In other words, we not only provide information on our website, we show exactly how the product works in demo form. This means that organizations can very easily evaluate the product on their own schedule with as many people participating as they'd like.
  • We allow organizations to try out the products prior to purchasing them (aka trial versions). This took a bit of engineering effort on our side, to ensure that when a trial period runs out, that the products stop working; but from a sales perspective, this has been more than worth it. Just two weeks ago, we were working with an organization who couldn't get all the people together on a conference call to ask us questions about the product. Instead of cancelling the call, we used the hour to install a trial version of the product in one of their environments and they were able to see that it would work as they needed (thus taking all the technical and operational risk out of the equation). They're well on their way to becoming a customer.

Pricing
Pricing is the other aspect of sales that we spend a lot of time discussing. When we first started the company, we discussed our plans with many of the early PeopleSoft employees, asking them about pricing, thinking that they'd have a magic answer for us. And, guess what... there was no magic answer. Joel Spolsky has a very good posting to discuss the issues from a general pespective (but for the sake of simplicity, didn't delve into the fact that you can also choose several of the things that are fixed in the analysis).

For us, we needed to take into consideration many of the assumptions about our business and the sales process (much of which was accurate, but much of which wasn't). One of the things you'll find as you look at the rest of this section is how much we look at internal factors that probably shouldn't be considered in setting a price. This is because we believe that by offering the best price we can to customers, we can use word of mouth to get other customers (feeding into our viral marketing strategy). Anyways, here are some of the factors that drive the pricing of our products:
  • The competition. For us, there are 4 ways that we lose any given sales opporutnity:
    • The prospect develops something to solve the problem internally.
    • The prospect hires a consultant to develop something for them.
    • The prospect upgrades to a new version where Oracle has solved this problem (fyi... this hasn't happened to date)
    • The prospect decides not to solve the problem after all
    Of all of these scenarios, the consulting one is the only one where pricing is a pertinent factor (I could go into why, but that would be a completely separate blog entry)
  • How the price of the product affects the amount of time it takes for it to pay for itself to a customer (ROI).
  • How the price affects cost of sales. A higher priced product will generally take more effort to sell than a lower priced product.
  • How the price of the product affects our margins.

One thing that jumps out pretty quickly in all these factors is that it's hard to get good, objective data to make these decisions and how it's easy to undervalue important aspects because they're hard to measure. Here are some things that we've learned in this ares:
  • Using consulting as a benchmark undervalues much of what we offer.
    • We eliminate almost all of the risk for the problem we solve. The price is fixed, the product either works or it doesn't, and the implementation time is immediate.
    • Our products are easier to support. Because we have to support customers on a wide variety of situations, we have a lot of diagnostics and error handling built in.
    • Customers are not locked into one way of doing things. In other words, if an organization upgrades or decides to change the way they do things, it's relatively easy to do this with a product (versus a consulting engagement that was built to only solve one problem on one release).
    • If a customer has a problem several years down the road, there's somebody on the other end of the phone who can help them.
  • It's easy to undervalue your own internal costs of doing business. Because you don't know all your internal costs until you have a good sample of customers using those products, and because you can't justify a price to a customer based on these costs, it's easy to overlook this piece. Here are some things that we missed until recently
    • Cost of Services. Because we provide a high level of service with our products (even before the customer pays us any money), our prices need to take that into consideration (our marketing should as well, because many organizations require companies to pay additional consulting for what we include in the product).
    • Cost of sales. One thing we underestimated was the amount of effort it takes to close business that has essentially been won. In other words, you've gone in, made the case, provided a trial version with the exact configuration of the production system, and the customer's ready to buy. Pretty easy from this point on, right? WRONG! There are all sorts of things that add costs from this point on: getting the budget approved or the budget manager to spend the time to buy the product that the project team has been working with, getting the purchasing folks and legal folks to agree to the language in the license agreement are two that can be problematic.
  • The price we charge has not had as much of an effect on the effort to close business as we had thought. It appears that although pricing is an important factor in justifying a purchase, other factors can be just as important or more important and a lower price generally can't reduce the time or risk in these areas. These include:
    • Release plans
    • Competing initiatives (mainly from a time perspective)
    • Purchasing and Legal (one that we really hoped could be streamlined with a low price... the thinking is that if the dollar risk is low, then the purchasing and legal process would be streamlined... what we missed is that the other areas of risk are more important to them than price at this point in the process)
So, what does this pricing discussion mean? For one thing, it means that our early customers got really good deals from us. It also means that as we get more data from each PeopleSoft customer we talk with, we have better information to help us get better at pricing.

Tomorrow will be the 3rd installment of this topic, where we'll look at the parts of the business that are not directly on the sales and marketing side: Engineering, Support, and Administration.

Labels: