The Right Mix of Features

More from OneTeamConference... A story of Product Management.

It's probably not appropriate for me to expose too much of the discussion here - but there was an interesting discussion I was involved with at OneTeam, and I think it is emblematic of the challenges all software manufacturers face when they have different "levels" of a product.

In this case, it was Vault (free, Data Management Software) and Productstream (real money, Vault + Release/Change Management, BOM, ERP integration, etc). They're down to the wire on the next release, and they're still not sure if certain features are going to be made available in Vault, or only in Productstream.

Why is it important? Well - the tough calls are when the features in question could potentially remove or reduce the compelling reasons for people to move from the (inexpensive/free) product to the more complete product.

For example, you can add a feature in Vault which is a great feature - but a side effect is that some people may use this feature in a way that allows them to implement limited change management - thus removing one of the compelling reasons to move up to Productstream.

Why would users do that? Well - users are fundamentally thrifty (my nice word for cheap) in many cases... They try to completely exhaust what is possible in the inexpensive product before moving up to a more expensive product. In fact, I've seen many cases where users invest far more in making something free work (often working badly) than it would have cost them to invest in the more advanced technology... Is it everyone? no - but in the SMB engineering space it's a very measurable percentage of the population.

In a kind of funny twist - I've been accused of doing that in the past with our Vault Access product (that is to say, the manufacturer getting miffed at a channel partner)... removing a compelling reason to upgrade by providing visualization and printing capabilities within Vault...

Maybe my views have changed a little over time, but here's my thoughts in the end:

• Segment your markets - understand if some people just won't need the higher functions, and accept that.
• Depending on your segmentation, you only owe so much to the "free customer"
• If customers will reasonably make a "stop" on the free version before moving up, then make sure that there's enough there so that they can work (if going to Vault first is a step that it's acceptable to take - don't prevent them from going to Vault).

This has another potential wrinkle, late in the game... Because Vault/Productstream clients actually use the same API that developers have available - Autodesk will need to be careful not to just "turn off the buttons" in their client... Or else some developer is going to write something that implements this "hack" of release management.

I'm not sure if it was clear from this post - but I'm actually supportive of them pulling this feature back - so that it's only in the higher-end Productstream... If customers were going to this length to implement this poor release management - then they ought to be really addressing release management with Productstream - and Autodesk and the channel ought to be doing a better job of these Vault Power Users to convince them of that.