A Tale of Two Universes (Selling “Vaporware”)

We’ve all heard the term “vaporware.” Software companies are notorious for selling it. It has become such an invasive practice that customers expect it.  


It seems all right at first. The Sales guy has a hot new client. The software “almost fits” their needs. It’s just missing a few fields here and there, a little function over here, one over there. He sits down with a member of the engineering team. “Can you mock up what this would look like?”

“Sure,” says the engineer. “That would be pretty easy to add on.”

“What about this function over there?”

“No problem,” says the eager engineer. He can envision how it would be implemented and it isn’t that large a stretch.

The Sales Rep goes off to his next customer meeting with his “demo” and powerpoint slides in hand.

“See – we understand your business issues, we can take care of your needs.”

The customer debates a bit but three months later, the contract is signed, software purchased.

The Implementation Team has been selected. Before they head over to the customer site, the Services Manager calls the Services Lead into his office. “One thing you should know. The customer thinks the product does this and that and has these functions.”

“What?” says the concerned Services Lead. But it doesn’t!”

“Can’t you just configure it on the outside?”

“It doesn’t work that way! We need some product changes.”

“That’s OK – the engineers said it would be easy.”

The Services Manager goes to the VP of Engineering. “When can we have this product upgrade?”

“Product upgrade? We’re just starting final test right now for our major release. If we put this in now it would delay the release significantly and we have customers who are planning on this schedule.”

“But it’s a ‘must have’ for our new customer. Sales committed to it!”

The Executive Committee has an emergency meeting. Engineering is directed to create a branch in parallel during their final test sprint to try to get these features out right after the main product release, against their policies. The new features will be released 1 month after the major release.

The concerned Services Lead is told that they will just need to “fudge it” for the first few months of the implementation project.  

“It’s OK”, says their Manager. “The customer is using the Waterfall method and are first going to firm up their requirements, then spend a couple of months on detailed design. By then the release will be ready.”

An uncomfortable team heads over to the customer site with their instructions. They had been directed that during requirements review, to pretend that the features are in the product and check off the requirements associated with the new fields and functions as “OOB” (out-of-the-box). “It’s all right”, they are told by their Manager, “because they will be in the product real soon.”

During the detailed design phase the customer starts asking to see the product to help them envision the customization changes they are designing. The Services team knows many of the big features they expect to see there just aren’t there. There’s tap dancing.

Eventually the customer figures out that the software isn’t all there. The truth is out. There is a huge blow-up and the customer calls the CEO to complain. The CEO assures them that their features will be in the new release. They are still upset but sit down with the frazzled Services Lead to iron out what a viable implementation schedule would be including incorporating the upcoming product release. They start their work on the current release for customizations that don’t require the new features.

The new release is delivered and the customer’s policies require a total re-test. While re-testing they uncover minor changes in the completed configuration needed due to the new product enhancements not being exactly how they’d envisioned them. Because of re-testing and re-work, both cost and schedule are impacted. Although the contract was “Time and Materials”, they call the CEO and refuse to pay any extra cost due to re-work and he concedes. Still the project costs them more money than planned due to the schedule impact.

The customer isn’t happy but is used to software companies that are less than truthful. Standard practice, they grumble. The skilled Services team eventually delivers the final solution but the customer is less than thrilled.

Replay in a Parallel Universe


The Sales guy has a hot new client. The software “almost fits” their needs. It’s just missing a few fields here and there, a little function over here, one over there.

  He sits down with a member of the engineering team. “Can you mock up what this would look like?”

“Sure,” says the engineer. “That would be pretty easy to add on.”

“What about this function over there?”

“No problem,” says the eager engineer. He can envision how it would be implemented and it isn’t that large a stretch.

The Sales Rep sits down with the Engineering Manager. Here’s the features and functions that Client X will need if they buy the product. Is it feasible to get them into the current release?

The Engineering Manager and Product Manager have a quick meeting to determine the feasibility. They will need to move some features out of the current release now to make it happen but there are no clients waiting for those. She gets back to the Sales Rep with an “OK – as long as the customer can commit within the next few weeks while we still have a few Sprints left.”

The Sales Rep goes off to his next customer meeting with his “demo” and powerpoint slides in hand.

“See – we understand your business issues, we can take care of your needs. These few functions are not in the software yet, but if you buy the product the Engineering Management team has agreed to provide them in the next release which will meet your schedule. If you can sign the contract this month.”

The contract is quickly signed, software purchased.

The Implementation Team has been selected. During their internal kick-off meeting, before they head over to the customer site, the Services Manager calls the team into his office. “One thing you should all be aware of. There are a few features that are missing from the product but engineering has already agreed to deliver them in the upcoming release which meets the customer’s schedule. The Product Manager will work with your team and your customer to make sure we build the features the customer is anticipating.”

“Great.” says the Services Lead.

During the detailed design phase they start reviewing the product and proposed changes. The customer can provide input into the new features and iteratively they improve on them before the product development team has started their coding. In fact, they find a way that the product changes can be implemented that remove some of the customizations that had been bid, saving the customer implementation money.

The project is completed on-time. The customer feels they are part of the team and the vendor is the best vendor they’ve ever worked with. They will definitely consider this vendor for their next project.

They are happy to give a Press Release and authorize a marketing blurb for the vendor’s website.

Why Sell Vaporware?


Why do software companies feel they need to sell vaporware? Some misguided notion that customers won’t buy a product unless it has all features today?

The second scenario brings everyone on-board. The company is collaborating. The customer is respected.

Having worked on projects sold both ways, I can attest that the second, honest and up-front scenario is by far the best.

13 Tips for a New Software Start-Up

I was lucky enough to be the Co-Founder/VP Engineering, then CTO of a great start-up. Great in so many aspects:

  • Great partners
  • Fun, intelligent, hard-working team
  • Customer-driven product vision
  • Successful product deliveries
  • Supportive Board
  • Happy, loyal customers
The best job I ever had!   Intelic

What tips would I give to new software start-up entrepreneurs about Do’s and Don’ts for software start-ups?

Jan’s 13 Tips:

  1. Pick your partners/executives well. Co-founders and/or executive team needs the same vision and priorities and ideals. The team needs to trust the leaders and the leaders need to trust the team. Management needs to talk the talk AND walk the walk.
    Management Team

  2. People, people, people. Hire smart, hard-working engineers. I quickly recruited key engineers plus found a local company to provide consultants for a quicker ramp-up. If someone isn’t working out, do the hard thing that’s right for the rest of the team. Make the cut. This can be really, really tough and we all want to make it work out, particularly for nice, eager folks. But in a really small team, everyone needs to ramp up quickly and contribute.

  3. Don’t Over-hire. This one didn’t seem intuitive to me at first but worked extremely well for us. Our CEO had the belief that it’s human nature for people to always find work to fill their day. No one in a start-up is ever “not busy” – but are they busy on the right tasks? Another way to look at it is “focus”. If there are “just enough” people, then only the important tasks are done, instead of a lot of non-essential activity. In a start-up, non-essential personnel could include managers who aren’t hands-on part of the time, project managers there just to track status, IT resources, etc. Instead, initially hire for the key spots: Sales/Marketing, hands-on Engineers (including somebody that will also manage), one Finance guy (unless the CEO is also an MBA then they cover it). When the product is ready to be released, add services people, IT, Finance, and someone at the front desk.

  4. Keep the software team co-located. Nothing is as distracting to a small software team as trying to establish a remote, off-shoring facility. Team focus is extremely important.

  5. Focus on delivering what the customer wants. If you’re lucky, you’ll have what we had – early employees who had worked in our target business area that were smart and knew exactly what the customers wanted. If not, find those people – they are key to your team. We built a prototype. Showed it to perpective clients. Got feedback. Updated the prototype. On the day we officially formed the company, we had a robust prototype (HTML screens and flow) plus our first customer and $1 million from Angel investors (most of whom were also from our target business area).

  6. Focus on delivering what the customer needs. If you’re building the software, also think about all of the aspects of the product including how the IT managers will want to customize it, install it, take releases. Plan for that up-front in the way the software is architected and built. We did this in the first release through business properties so the clients could change business policies to match their needs. Also the code read from resource files that contained every word displayed on the screen, including error messages (I highly recommend all software be designed this way) so the clients can use their own terminology easily or even localize to different languages. Later we added a GUI configurator. The easy installer was built in an early release. The upgradability was part of the development thought-process. If you’re building software that needs to be installed and upgraded, this is key. If you’re building cloud software then you’ll obviously need to have easy configuration, install and upgrade tools. And plan for global users – review how “time” affects your application and if important (e.g., contract start/expire timestamps) convert to UTC/GMT global time and build functions to handle time appropriately/consistently.

  7. Pick the right architect. Monitor initial concepts and progress and pick as the key architect the engineer with the best sense of a clean and simple design, regardless of whether he had the most experience or was your initial architect candidate. The right architect is key to product success!
    Keep it simple

  8. Keep it simple. Don’t try to build an architecture that will be everything to everyone – build what you need. Refactor as you go along if necessary to keep the code clean and efficient. A simple framework will be quicker to develop new features on, more reliable, and more maintainable.

  9. Don’t be afraid to build it. Your CEO may say to buy, lease, integrate but for a small company if it keeps things simple to build, keep it simple. Originally we used a 3rd party object-to-relational layer. The night before a major demo it failed. If two people clicked the same button at the same time on their separate browsers, kaboom! We limped through the demo by having copies of the app running on each training system instead of the normal browser configuration. Our architect had, for fun, built a layer for his own use and we quickly migrated to that. It was exactly right for our needs. Simple, clean, just enough. Someone years later asked me if I were to do it again if I wouldn’t use Hyperion, said he would. “Better to buy than build. Better for the engineers resumes,” he said. No, I’d do it exactly the same way but start with the build, not buy version. There are exceptions – I wouldn’t build my own relational database, Java compiler, charting package, etc. But I’m not one for adding tens of thousands of external library files to my release “just in case” one of the handy, dandy tools comes in useful. Keep it simple.

  10. Implement a Practical Software Process and Tools. Choose a software process and tools that are simple and streamlined while you’re small but that can grow and support a scaling business model. Our recommendation is one tool that handles your key process (e.g., Agile story management, task tracking) and provides on-line automated spec viewing.
    Software 2020

  11. Focus on quality. Fix the bugs as they are found. Use a quick, iterative method for ongoing maintenance releases. The only bugs that should not be fixed ASAP are ones that are found internally due to some weird, illogical path through the software or that are so small and cosmetic no one will notice them. DO fix even small bugs that are cosmetic if they are visible on the screen (typos, etc.) as they detract from the professionalism of the software. To streamline the process, use a good bug tracker tool. Have a cross-functional team meet weekly to review new bug reports and keep the funnel flowing. We called it our SDRB (Software Design Review Board). In the early years the head of each cross-functional group would attend, including the CEO (who was also Product Marketing). As we grew the QA Director was the lead but still heads of each org attended: Director of Customer Support, VP Engineering, VP Product Marketing, etc. The top person would attend (if in town), else his/her delegate, so decisions could be made at that meeting and each new bug report allocated to the appropriate release. That way, bug reports and client issues don’t get revisited again and again but are reviewed and assigned to the right delivery timeframe once, promptly.

  12. Focus on application speed, performance. Performance is an extremely important aspect of quality. At Ford Motor, when they built CAD/CAM systems internally for their car designers, they found that more than a second delay in when the designer clicked the light pen to when the screen responded would cause the designer to lose focus and made the tool less effective. Screens must be blazingly fast. Anything taking more than a few seconds needs to give the user the option to “click refresh” or go elsewhere to do work while the screen completes (not hold the user hostage until the processing is done).

  13. Lucky # 13 – Work hard but have fun. We had off-sites. Most importantly, we worked to be sure that everyone, even our Indian consultants would attend them. So the entire team became a close-knit group and everyone was treated with respect. We had yearly “Star Wars”, then “The Matrix” movie outings where our CEO handed out hot dogs and popcorn. Make “fun” part of the culture, part of the daily dynamic. The engineering group had fun with humorous email comments (always respectful but cute). As a manager, play along, encourage it. Don’t be stuffy. We added ‘quotable quotes’ to our bug tracker tool so every time someone submitted a new bug or enhancement request, they saw a random quote. Something someone had said but taken out of context and therefore very hilarious to all of us. At cross-functional meetings when someone says something that can be misconstrued, someone will say “Ahah! Quotable quote.” and it will end up in the system. The more a team is willing to be playful, it shows they trust and respect each other.
    Quotable Quote

    As another example, decorating the cubes when someone goes away on vacation. My favorite: The engineers were going to nail a big piece of plywood over our Dev Manager’s office door when he went on vacation but I said “No nail holes in the building!” (We were leasing after all.) Just then our CEO came up and saw what the engineers were about to do. “Wait a minute.” he said and darted away. He returned with his power drill. “We need this! Nails won’t do,” and proceeded to tightly drill, screw, and seal the plywood over the doorway. Gary sure had trouble getting into his office when he returned 🙂

    Of course, the fun is part two – the tip is “Work Hard” THEN have fun.

Rainy Days and Mondays

Sounds like a song title.  But neither rainy days nor Mondays get me down now-a-days. In fact, just the opposite. Now that I don’t need to get up before the crack of dawn, get in my car, and drive two hours to get from Discovery Bay to work in Silicon Valley but rather can work from home looking out at the water and my ducks, with a nice fire going in the fireplace, I really like rainy days and Mondays. Cold, rainy days give me justification for having the toasty fireplace going all day. And Mondays I’m refreshed after having taken a little break from work (although my husband does think I’m basically glued to my computer even on weekends). And now-a-days I’m focused on a different kind of rain.

In January it rained. Referring to both the weather and the work. Good for the pocketbook but not good for my fledgling Duck Pond Software and my newly proclaimed entrepreneurial vision of the new company of the 2000s. In other words, I spent almost full time contracting back to my prior company Model N.  I did most of it working from home, so it wasn’t like I gave in totally to the corporate structure. And it was fun. But still .  .  .

The first half of January was more typical for me – part-time Model N work (split between getting my briefings ready to present at Rainmaker, the Model N user conference to be held in February in Phoenix, and on designing a new Rebates module) and part-time moving Duck Pond Software ahead with potential partnerships and customers. Then mid January I got a call from three Model N managers all excited and panicky because of a potential hot new customer deal and marketing arrangement if they could get their software integrated with SalesForce.com tout de suite. This meant an immediate full-time diversion in order to get a live demo up and running in a couple of weeks. The CEO wanted to make an announcement at Rainmaker about a Model N/SalesForce partnership. It was, to our CEO, one of the biggest announcements Model N had ever made. Besides diverting me, they said they’d assign Freeman full-time. That’s what made it fun.

Freeman and I have worked together for about 15 years through four companies. I hired him initially right out of college. He proved himself quickly, becoming the software architect at Azerity. He’s a brilliant and creative engineer but at the same time practical, down-to-earth and loads of fun. He was probably the first engineer who worked for me who was the age of my daughter. But rather than making me feel old, his wit and liveliness always kept our work fresh and fun. Plus he lives and works in San Diego (Model N’s one remote software engineer besides the offshore team in India) so my working from home wouldn’t be a problem on this project at all since he would be working from his home too.  
Long story short, we spent two hectic weeks but delivered the demo, got kudos from everyone, and the CEO had the joint announcement for Rainmaker. And the January paycheck was also very sweet.   But in the end, it’s just a paycheck received while building on another entrepreneur’s dream versus building momentum towards my own dream.

It was the last hurrah for Freeman and I working together which made it a bitter-sweet success. Freeman joined a start-up locally in San Diego at the end of our project. He’s going for the entrepreneur dream getting in as the third member of a team not even officially a company yet. However, I wouldn’t be surprised if we work together again some day. .  That’s the cool thing about the new companies of the 2000s. It’s like the website LinkedIn and other networking sites that are springing up.  People in this century want to be building their own dreams, not working for big corporations where there’s a single entrepreneur who’s the only one who ever makes it big.  We all want it our own way

We want to make our own rain.

A company for 2008 and beyond.

While I was pondering the last few weeks about what to do with my new “retirement” spare time and my newly-negotiated rights to SD Tracker, I was spending time surfing the net (I can’t golf 24 hours a day). Several different things came together in my mind’s eye as a flash of intuition. My son-in-law Shane is ahead of me on this, but for me it was an epiphany. As I said in my prior blog, I was weighing options – full-time retirement (lots of golf), another exec position in a start-up, my own company, writing those books I’ve wanted to write, or something else. But what? What form would my days now take. And that’s when I realized that there’s a new kind of corporate structure starting to appear for 2008 and beyond – and it shows a lot of promise. There were three prongs that came together to form my ephipany.

First, my daughter Julie had been pursuing (in addition to working on her PhD) an alternate type of job in multi-level marketing (MLM). MLM – own your own business, build recurring revenue, have independence and financial security. She saw mlm as the alternative to years of 8 AM to 7 PM jobs with no vacation, pressure and only whatever savings you could religiously put aside to use at the end for retirement. Instead, her thought process was that the NextGens should push to break out of the envelop and look at work and life differently. I mean I loved being a co-founder in a start-up and building a traditional business. But when it came down to the bottom line, it’s the VCs that almost always win the big bucks and the rest of us are back to the grind stone. Recurring personal revenue – could that be the key? But after years of dedicated determination working to build the team needed for the sustained income that the MLM dream paints as the reward, she found pitfalls in that you still need to rely on the parent company’s management to not make dumb decisions, not jack the prices up, not make marketing decisions that totally wreck your game plan. So that didn’t seem like the nirvana it claimed to be. So then what?

With my semi-retirement and newly found time on my hands, I was browsing my son-in-law’s website since he’s been after me to add a blog, but, well, although I’ve been building web-based software for years, I must admit I haven’t jumped on all the social networking sites (FaceBook, YouTube, and the likes) and haven’t taken to blogging. Shane joined with a partner Peter to start a new company Shane & Peter and their business is skyrocketing. I have to admit I didn’t see it as a real business for the first few years – I mean the guy was giving away websites in exchange for everything from the wedding cake to the wedding dress (not that I’m complaining – it sure did help out on wedding costs). But then I started reading his blogs and I think he and his friends may be onto something here. It’s a new type of business model and it seems the internet is a-buzz. New internet companies are springing up and everyone is trying to figure out how to convert them from hobbies into substantial money-making ventures. A bunch of them are referencing Shane’s articles on Shane & Peter. Shane seems to have hit upon the goldmine approach and is leading the charge from the old type of corporate structure to new companies forming instead that are network of consultants, contacts, other companies like them. Shane & Peter can quickly and effectively put together a team to meet the needs of major corporations. Shane & Peter’s client list is impressive and proves their new corporate structure works. So that was the second prong, the second “Ahah”.

But it’s not just occurring with the NextGeners. The third prong in the wheel was when we (my husband Mike & I) traveled last summer to Canada and on the way stopped off at friends house we haven’t seen in years. Bob was one of the first folks I knew to leave the big company (Microsoft) and venture out on his own starting The Socrates Group. That was bought by another company. Today he has re-started The Socrates Group but in an entirely different structure – a group of loosely-networked consultants. Not everyone needs to belong to the real “company”; most are independendent contractors. Starting to sound familiar? It’s allowing him to be independent, creative, but maintain control of his own destiny. Same solution for a Baby Boomer hippy as well as a NextGener.

So I’m thinking that it’s 2008 and time for an entirely new type of company. The individual entrepreneur, the loosely linked team of professionals working their own way on their own time. See Shane’s blog linked to my home page. Shane and Peter started their company in a coffee shop but as their friend Quinn blogged Coffee Shops are So 2005. Quinn’s “office” is his fully equipped, satelitte antenna/wireless VW camper. So what is the Corporation for 2008 and beyond?

I’m not sure what it “is” but I know I want to move into 2008 – it’s time to combine the joy of living on a duck pond (my new company motif) while linking with a wide assorted network of professionals leveraging their talents and together providing more benefit to existing major corporations than any of us could individually or as part of a single large corporation.

That’s what I’d like Duck Pond Software to be all about – exploring a new kind of company and helping other companies while I’m at it. Because regardless how the software is being built and the projects and services are being implemented, the basic processes remain the same.

Because just as the old aerospace tools and techniques were refined and simplified over the years and for my start-up, Azerity, made us lean, effective, and efficient, those same web-based tools and simple basic methodologies can help the NextGen companies (and even ex-hippy companies) in 2008 and beyond.

Retirement or Another Start-Up?

After more than 30 years in the software business, I’m not driving to work every day. Surprisingly, I left my prior company without having a new company to go to. My husband says I’ve “retired”. I don’t know what that means. The beauty of being in software is that as long as you have access to a computer, you can do all of the fun activities you did at your job (but just not get paid for it – humm.)

I’ve worked in the big aerospace and defense software world, been a software exec in various commercial software companies, done the “start-up” bit. I’ve proven that the “80’s” development practices and procedures can be leveraged and changed to work for the 90’s and 2000’s. I might say (humbly I hope) that I always was a great software manager – my reputation was on-time delivery, teams that were motivated, all that good stuff. At my own start-up, Azerity, we produced a product that competed with the big gorillas (SAP, Oracle) and won every time. I’m not stretching now – that software was used by major corporations for mission critical tasks (quoting, pricing) and was reliable (never crashed – really), scalable (30,000 users worldwide), and high performance (just what you want from a web-based system – click click click – screen after screen snap, snap, snap). And it didn’t cost the clients millions to install and millions more to upgrade (semiconductor companies may be big but they are very, very cheap!) When we were bought by a bigger company, within 9 months, the acquirers made more in software sales of our product than they paid to buy the company.

So I went back to the company that acquired Azerity and negotiated the rights to relicense the tool we’d built, SD Tracker.

So now the question is this: Go back as a VP Engineering at an existing company and use SD Tracker and processes and lessons learned and do it all again? Take SD Tracker and start a new start-up going after VC funding and that whole gig? Golf every day? Or some combination of all of the above.

By the way – the other change last year was moving out of Silicon Valley to Discovery Bay – “Live where you play in Discovery Bay” is our city’s official tagline. (Or an alternate is “A small drinking town with a boating problem.”) Both fit. Wonderful place to live – BUT, a 2 hour drive to Silicon Valley where the companies and action are.

We built our house on Drakes Drive, have the Delta (Sacramento River) as our back yard. Wake to the sounds of ducks, geese, and seagulls outside our bedroom window, golf on a lush course abounding with lakes (i.e., duck ponds). Seeing a theme here? So I named my fledgling company “Duck Pond Software”. At a minimum it’s my DBA for consulting back to my prior company for a while. But … maybe more…