We've been remiss in updating our customers page. We would like to welcome the following organizations to the Grey Sparling family:

• U.S. Department of State
• Cherokee Nations Enterprises
• PMI Insurance
• Fleming College
• Rapp Collins Worldwide
• The Marketing Store
• Methanex Corporation

Labels: Business

Back in the early days at PeopleSoft we used to ship software on floppy disks. A whole boatload of floppy disks. There was even this really cool floppy disk duplicator that we had where you would load in a stack of floppies, with the source in one stack, and blanks in the other. I think it could handle something like 50 disks at a time. Jay Hann would know for sure. Anytime the disk duplicator broke (basically whenever you looked at it), he was the one to get it going again.

Then this magical thing called a "CD" started getting popular enough that we could ship all of our software on 1 CD, and have room to spare. Wow! It wasn't quite as good as regular backup tapes, but still a huge leap forward.

A quaint blast from the past, eh? Well, I felt like I was transported back to that same era earlier today while looking at various escrow services out there (that's "escrow", as in code escrow, not escort services Mr. Spitzer). You see, we ship a lot of source with our applications, but we do have some parts that we do not ship the source to (and yes, just shipping all the source would make the question of code escrow go away). We had a customer ask about source escrow recently so we started looking into it.

The various escrow services all seem to be focused on the idea that once in a blue moon you will have a software release, send them physical copies of the software, and they will provide announcements that you have done so to the customers that you have deemed as beneficiaries. All this for several hundred dollars per customer per year.

Even worse, it doesn't appear that those entry level prices include much in the way of validating the code. A recent CIO magazine article about source code escrow mentions an incident with Radisson Hotels where they ended up having to get code out of escrow, but couldn't use it, because it was missing objects, etc.

The article does have several comments that complain that the authors should have mentioned that best practice is to "audit" the code escrow. But, none of the commenters, nor the escrow sites, has any good details about this audit would be performed. I'm sure that people with regular code escrow experience know a few tips and tricks about this, but I don't see too many of them blogging :-)

In a perfect world what would happen is that when we signed up, they'd give us a Subversion post-commit hook that we could use to mirror our version control commits to the escrow service. Then we'd give them the configuration for our Continuous Integration server (we use and love Hudson), so that the escrow service could run the same builds that we do. Heck, they could even use Hudson's email notification services to send the build logs and unit test results to customers as proof that they are actually receiving code and it is at least in semi-decent shape.

For the customer that then wants to do even more auditing, the escrow service could make the generated binaries available for the customer to test with. If those still work properly, then that's a pretty good sign that the escrow service is working properly.

The crazy thing is that this wouldn't be all that hard to do, or even that expensive. Maybe you wouldn't want to actually send all of your commits over, but it would be easy enough to limit what gets sent to release branches and not current development work.

The biggest challenges would be things like customer A is only entitled to version 1 plus maintenance releases, while customer B gets everything, etc. But figuring out those details is the value add that an escort (whoops - escrow!) service can provide. Most of the rest of it would just a bunch of hosted servers and some fairly standard configuration.

So will someone go build that so that we can toss out the CD burner. Please.

Labels: 2008, Business, VersionControl

First, Oracle acquires Hyperion. Next, SAP announces an acquisition of Business Objects. Today, IBM announced it will acquire Cognos. It looks like the only major independent BI player is MicroStrategy.

This acquisition provides a lot of food for thought. With the combination of Ascential and Cognos, IBM will have a complete technology solution from data acquisition, cleansing, all the way through data access. Additionally, these technologies are best-of-breed technologies brought together in one umbrella.

Technology Play
Although this is a good technology play, I'm still of the belief that the days of building your own BI solution from soup to nuts is not the way the market is going. This is a good strategy under yesterday's model. It's my belief that Oracle and SAP have the right long-term strategy, which is to provide analytic applications using their own technologies. Companies don't want to build expensive data warehouses and their own analytic applications if they can buy one that somebody else has developed. Also, by bringing together analytics with their business processes, organizations can achieve benefits that can't be achieved with a BI framework that is silo-ed off from their transaction systems.

Why not Analytic Applications?
Back in 2002, IBM had the opportunity to get in the applications business. We at PeopleSoft were hoping that IBM would be our white knight and save us from Oracle. There was quite a bit of effort going into discussions in this area, but in the end IBM didn't want to get into the applications space. They wanted to stay a technology/consuulting organization. Now, that opportunity is pretty much gone unless some sort of mega-merger occurs between IBM and SAP or Oracle (which I can't see happening). So, it will be very interesting seeing which strategy works better. My money is on Oracle/SAP with Cognos becoming less relevant, but this assumes that Oracle and SAP are successful in integrating their new BI acquisitions (Oracle seems to be doing a pretty good job, at least from a PeopleSoft perspective).

Labels: 2007, Business, Cognos, Reporting

Oracle is going to make life easy for the PeopleTools product managers if they keep acquiring all of the 3rd party products that PeopleTools embeds :-)

Joking aside, an Oracle acquisition of BEA would mostly be a non-event for PeopleSoft customers. Sure, there's potential for some of BEA's middleware to become of the Fusion stack down the road, but purely for the purposes of running current PeopleSoft applications, nothing would be likely to change (except for the logos on the installers!).

As was the case with Crystal and other 3rd party products that PeopleSoft used, there were long term contracts in place for Tuxedo and WebLogic. These contracts always included language that dealt with acquisition scenarios, including scenarios where the acquirer was hostile to PeopleSoft. Fairly standard stuff in terms of protecting yourself from the unexpected (or maybe these days you'd call it the expected).

Of course, even long term contracts do come to an end. Since Oracle is going to support PeopleSoft for some lengthy period of time, how to handle 3rd party products over the long haul still is an interesting question. When a contract comes up for renewal, there's always the chance that negotiations won't go well. As a product manager, you always have to have a backup plan ready in case you suddenly need a replacement.

I had an interesting lesson in this one time when my boss at the time, Peter Gassner, drug me and Tressa Novak, who ran the Business Development group for PeopleTools, into an extraordinarily long meeting with a vendor that believed that they had PeopleSoft over a barrel at contract renegotiation time. I won't mention their name (but I will tell you that they haven't been mentioned at all on this blog), but they brought in a few high level folks that had barely contained smiles on their faces. The anticipation of a giant payday must have been pretty strong.

The next few hours were spent with Peter slowly, but surely, convincing them of exactly how PeopleSoft could move away from being dependent on them, what the effort would take, what the problems would be and how they would be dealt with, etc. It was interesting to watch their smiles very slowly turn into frowns as they realized that they didn't have quite the leverage that they thought they did. They left the meeting room without the smiles, but still as a PeopleSoft partner. Without the detailed backup plan in place, then the negotiations surely would have turned out much differently (probably with them making Sales Club for the next few years!)

It would have been pretty funny if we had just said that we were going to buy them instead :-)

As for backup plans for WebLogic and Tuxedo, those are taken care of as well. Replacing WebLogic if absolutely necessary would be easy to do since Oracle's own J2EE server as well as IBM WebSphere are already supported choices.

Tuxedo would definitely be a harder effort, but PeopleSoft actually doesn't leverage Tuxedo so deeply that it wouldn't be possible. In fact, most of what PeopleSoft gets from Tuxedo is also supplied by leading J2EE containers these days. The bigger headache is that the PeopleTools code that runs as Tuxedo services is written in C++. Using JNI to make that work inside of a J2EE container wouldn't be pretty, but PeopleTools already uses JNI extensively for all of the Java/PeopleCode integration. Not a pretty solution, but as a backup plan, it's manageable. Certainly more so than porting all of the PeopleTools C++ code to Java, which was bandied about on a few different occasions.

Labels: 2007, Business, History

Yesterday's news was very interesting. I had intended to comment on this much earlier, but ended up spending a lot of time on the phone last night talking with people who wanted my perspective on what this means.

The rumors about a big acquisition in the BI space is nothing new. In fact, a big piece of PeopleTools 8.46 and PeopleTools 8.48 was to protect Oracle from SAP acquiring Business Objects (now that this has occurred and I've been out of the company for over 2 years, I'm more or less free to talk about it).

So, Why would this be inevitable?

Good question. It's a combination of needs and market forces.

Looking at it from the BI Side

On one side, you've got BI vendors who need to get data to report and visualize. Because a good portion of this data is locked up in ERP and CRM systems, their solutions are dependent on getting data out of these big, packaged applications. Anybody who's had to built ETL maps or figure out what table to use (and what the values mean) can tell you that this is a big, hairy, painful effort.

In addition, the BI vendors, by definition, are limited in what they can provide. You see, the ERP vendors own the key business processes that people perform. Sure, you can put together an executive dashboard for management without integrating in the business process flow that occurs, but you can only sell so many dashboards. What customers really want to do is to help employees do things with the information presented in BI. This is not something that a standalone BI vendor can easily provide.

Looking at it from the ERP Perspective

On the ERP side, you've got products that are optimized for capturing data, but not getting it out. The focus on SOA as the next big thing is a perfect example of how ERP vendors look at things. SOA is primarily focused on how you can cause transactions to occur across systems (placing an order is one of the most common SOA use cases quoted). Because of this, ERP vendors have, for the most part, either outsourced any BI they provide (ala Business Objects, Cognos, or MicroStrategy), or they have defined reporting and BI in very limited terms, so that functionality gaps can be glossed over.

For those folks wondering whether SAP's acquisition of Business Objects is a good idea, they should look at the reporting functionality provided with an SAP application. Game... Set... Match!

If done properly, the things that BI firms do well can dramatically improve the core functionality of an ERP application as well as provide new ways of providing intelligence within the context of business processes. Here are some things that BI can do to improve core ERP processing if adopted properly:

1. Navigation within the ERP product can be dramatically improved. Suppose that you had a high-end query tool as the means of finding items you wish to process ("I want to manage the inventory of every product that meet some set of complex criteria"). This means that your employees can more efficiently do the most important things to your organization more productively (one might say "intelligently").
2. Conditional processing, such as approvals can leverage BI functionality. In other words, you can use common definitions for evaluating trends of key risk metrics and automatically routing the approvals to the appropriate person (or better yet, to cause the evaluation of metrics to drive business processing). A report would then be a visualization of common calculations that drive your processes (ooooh.... aaaah...)
3. Reporting can be integrated with business process, so that it's easier for users to determine what data to use, and how to get the information they need. If you can close the loop automatically, by allowing the user to navigate back into the business process, now you're talking!
4. Providing better ways of navigating and organizing things. BI firms have already had to spend a lot of time figuring out how to organize and present data, logical representations of tables, and relationships to business people (versus developers). ERP vendors could learn a lot about how to facilitate navigation, organize content, and help business people do more within their products.

Therefore, I see lots of synergies, assuming that organizational issues don't get in the way of cross-pollination of assets or ideas. In fact, I've believed for a long time that BI truly seamlessly embedded into business applications will be the next big thing for ERP (sorry guys, not SOA).

What this means to the Market

SAP acquiring Business Objects has a pretty big impact on several players in the market. Therefore, let's look at its impact to the players in both the ERP and the BI marketspace.

• Cognos - Cognos and Business Objects are the two primary competitors in the BI space. In the short-term, Cognos will benefit, because it won't be distracted from its current plan. However, it is my belief that this will play out as being very bad for Cognos. This is because Cognos's major focus in the ERP area has been going after SAP customers. With SAP owning business objects, they have a better story on integration (which is the biggest cost of doing BI). Although Cognos could move down-market to capture additional market-share, their long-term survival will be tied to their ability to integrate with their customer's data and focus on beefing up markets other than SAP (such as Siebel, Oracle or PeopleSoft).
• Oracle/PeopleSoft - I'll start by looking at just the PeopleSoft applications aspect of this. PeopleSoft has embedded Crystal since 1994, and has packaged a majority of its production reports in it (well over 1,000 of them), and every PeopleSoft customer uses Crystal in one manner or other. Back in 2004, PeopleSoft's contract with Business Objects was up for renewal, we spent a lot of time looking at what could happen, knowing that we were highly dependent on Crystal. One of the first things we recognized was that we needed to lock in a long-term contract with them. One of the second was that our integration with Crystal was originally written using windows APIs that were antiquated and needed updating. Therefore, we made the decision to embed Crystal Enterprise and utilize Crystal Enterprise APIs from the process scheduler to ensure that we would be protected in the event of a change of ownership in Business Objects. Therefore, PeopleSoft customers are relatively protected in their Crystal investment.
• Oracle Corporate - From a corporate perspective, this can't be a good thing for Oracle. One of SAP's weaknesses is the difficulty of reporting. This gives SAP the ability to address that weakness. It also puts more focus on addressing some of the limitations that exist in XML Publisher, Concurrent Manager, and Collaboration Suite that Crystal Enterprise addresses (yes, I'm sorry to report that although XML publisher has a lot of great features with respect to PDF and Excel, it has some limitations). Don't get me wrong, I still give Oracle the lead in BI integration with their applications (however, I also believe that SAP will have fewer distractions in closing the gap because it has one BI tool to integrate with one ERP suite, whereas Oracle has 4 different BI suites that can be integrated with 4 different ERP suites).
• Microsoft - This is one of the more interesting organizations affected by this acquisition. Microsoft, for a long time has embedded Crystal in its development tools. SAP has worked extremely closely with Microsoft on Microsoft Analysis Services. Now, Microsoft has built its own reporting and BI tooling and is doing a lot more development in the ERP space. I believe that Microsoft would much prefer to have a relationship with SAP that would have had the potential to make SAP more dependent on them from a BI perspective (and would much prefer to have worked with Business Objects in a way that marginalized them more).

Conclusion

In case it wasn't clear in the previous dissertation, I am in the camp with folks who believe that SAP was smart to buy Business Objects. What will be telling, however, is whether SAP will be willing to leave some tools money on the table in order to deliver the next wave of innovation in ERP. Whoever does a better job of bringing Business Intelligence into their ERP product suite will be the 800-lb gorilla (that's a prediction).

Labels: Business, Business Objects, Microsoft, Reporting

Labels: Business

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: Business

The blog entry goes under the heading of "If Grey Sparling Solutions were a B-School case study". You see, the Grey Sparling management team is constantly looking at our business model and execution to see what works, what doesn't, and how we can improve. We had one of these discussions yesterday and Chris said, "You know, this would make a good blog entry, even though it's not a PeopleSoft tip or technique".

Although it's a little different than posts we've done in the past, I believe that it does provide some insight into how the PeopleSoft ecosystem works (a few months ago, I gave a keynote to a PeopleSoft user group that discussed how there's a rich ecosystem out there to help PeopleSoft customers leverage their investment in PeopleSoft better). I have a half-written blog entry out there that discusses these points (but I got distracted with other things).

I will split this entry into 3 parts (to make it readable). The first part is to define our niche. Part 2 will cover how we're doing in the areas of Strategy, Marketing, and Sales; and Part 3 will cover Engineering, Support, and Administration. Let's continue with Part 1.

Our Business Model
For those who are familiar with Business Plans, you can think of what's included here as a bulleted list that summarizes our business plan without the numbers added. For those not familiar with business plans (and don't want to buy a bunch of books, as we did prior to starting the company), the plan defines who the company is, the market it is going after, how it plans to differentiate itself, potential competitors, and other risks.

Who we are:

• We are a software company
• We differentiate ourselves from other organizations with the level of expertise we have with PeopleSoft. We are the PeopleTools experts. This is our corporate identity.

Who are market is:

• We focus on current PeopleSoft customers, which means we focus on larger organizations.
• Our products use technology to enhance PeopleSoft, regardless of the PeopleSoft application being used by customers (in other words, we do not limit ourselves to an industry or an application).
• These products do one of the following things for customers:
  • Reduce the cost of running and administering PeopleSoft
  • Improve end-user productivity
  • Improve controls
  • Reduce operational risk.

Our engineering and support strategy:

• Our products have minimal footprint and plug into customers' existing PeopleSoft infrastructure seamlessly.
• To ensure that our products are easy to set up, configure, and support, we include installation, configuration, and support services with our products. Whenever possible, we add features to our products to reduce the cost and effort of these items.
• Our products are priced, so that ROI to customers can be measured in days or weeks, versus months or years.
• Although services are a part of our portfolio, we are not a consulting organization.

Our sales and marketing strategy:

• We utilize viral marketing and web technology wherever possible.
• We do not have dedicated salespeople who do not have a role on the support side.
• We use technology to make it easy for customers to determine the fit of our products prior to making a purchasing decision. This means providing open access to recorded demos on our website and providing trial versions with support services of our products.
• We believe that every PeopleSoft customer will eventually be interested in buying one of our products, so we are willing to invest in relationships with PeopleSoft customers regardless of whether we see a specific opportunity. This includes providing free advice and even code to solve specific problems that PeopleSoft customers are having.

Now that we've defined our niche, our next blog entry in this series will discuss the issues and how we're doing with our corporate strategy, marketing, and sales.

Labels: Business