On Roadmaps and Future Product Features...

As some of you know, I'm more than just a pretty face. In fact, more years ago than I care to think about, I got my MBA because I was more interested in how and why technology got used in the enterprise way more than how it was implemented or what technology it was.

Of course, as with everything in life, the parts that I got out of the experience had nothing to do with what I expected. I've learned to keep an open mind (stop laughing and let me finish), and let things happen - when I do that - I usually have a much richer experience that I could have imagined.

At Progress Software, we're a technology company but, like any other public company, we are also a business. A business subject to rules... some obvious, others not so obvious. Assuming that the readers of our blog are made up of primarily, (1) customers, and (2) Progress employees, I'd like to point out one of those "less than obvious" rules we have to deal with. You see, we're pretty fiscally disciplined here at Progress; disciplined and conservative.

I've become a bit of an Apple fanboy and was reading an analyst article, when I came across the following paragraph discussing the iPhone:

Apple's management cautioned in its Q2 conference call that it will not be recognizing the revenue for any iPhones sold between March 6 and July 11 until after iPhone 2.0 is released. Peter Oppenheimer, Apple's CFO, notes in Apple's Q2 Conference Call, "Because we announced the specific new features to be included in the iPhone 2.0 release and plan to provide them to iPhone customers as a free upgrade in late June, we will delay the start of revenue recognition for all iPhones sold on or after our March 6th announcement date until the iPhone 2.0 software is delivered."

I recognized that necessity. You see, we have the same restrictions with regards to revenue recognition. If we tell you about a product future and you buy the product to use the future feature, we can't recognize the revenue. And, as a conservative company, we are very careful about our financials. Our investors appreciate that but I know first hand that our field staff doesn't, and our prospects question our direction when they feel we are being evasive.

SOA What? What does this have to do with SOA infrastructure? Well, if you're buying our SOA technology, you need to know where we're going - but, we can't always give you specifics AS MUCH AS WE MIGHT WANT TO! You need a feature and you wonder why we can't just commit to a date and get over with it. This is why. It's about revenue recognition, and rules that are placed on us to protect customers and investors alike.

Instead, why not use a different approach? Knowing that these are the restrictions that vendors with integrity are under, how can you get what you need without compromising the integrity of the process?

Let me ask you another question - before I answer that to get you thinking about how successful the current approach is - regardless of the legal restrictions we're under. How many times have you worked with a vendor who successfully delivered a POC with some custom feature (often integration with some other product I would bet), gone and purchased the product only to find that the feature delivered during the POC wasn't quite up to enterprise class? And further, what has your experience been trying to get the vendor to add the feature to the roadmap in a way that addresses your concerns?

So, how do you get what you need without compromising the integrity of those involved?

Talk therapy.

One interesting thing about our space is that we're deep in infrastructure, and purchases of our product, both large and small, tend to be strategic in nature. We're going to be together for a while. Why not get to know us?

I suggest the following sorts of questions:

1. What is the product direction and strategy? What problems does it solve and what does it do best? What won't it do?
2. What use cases do partner integrations satisfy, and where do those use cases fall in the product adoption life cycle? Why not get multiple vendors in a room together and have a mini-summit? A four hour brain dump? I find those informative for all involved.
3. What references can be shared by customers who needed features and worked with product management to get them appropriately prioritized and delivered?
4. What is the vendor's product delivery strategy? How many releases annually? What is the delivery/release strategy? For example, if you look at our minor-releases, they are often driven by customer enhancements. We use the rapid cycle of minor-releases to quickly address customer concerns as they start their implementations rather than forcing them to wait six months or longer for a major release. As part of our process, these minor releases are fully supported and part of the product in a disciplined manner.
5. How flexible is the product architecture to allow for enhancements? What is a typical timeframe for an integration of type X?

I know, talking about strategy is high-level, but... isn't it better to learn how we make decisions rather than to get an answer to the questions you have now? I think so. Remember, we're going to treat you really nicely when we're dating. What you really want to know is how we'll treat you once we're married.

That said, you know Dan and I from this blog. We spend more of our time talking to prospects than customers. There are two people on the team who are the reverse - though they talk to prospects, they spend more of their time working with customers. They are Vasco Kollokian, our Product Manager, and Julianna Cammarano, our Product Marketing Manager. I've learned tons by working with them. Why don't you try some of the questions above on the four of us, and see what happens?