The Fiducial Mark

Where does social media play into a Product Manager’s go-to-market strategy?  Earlier this year Pragmatic Marketing released their 2009 Annual Product Management and Marketing Survey.  While the survey covers many aspects of product management, I noticed that the survey included a section on social media.  In particular, one particular question asked: “How much influence is social media on your go-to-market activities?”  The results:

• 51% Considered it but it was not a significant factor.
• 40% None.
• 9% Major part of the program.

With regards to Twitter, 62% of respondents did not use it.  The survey also includes a number of sample answers, which you can check out for yourself on the survey results page.   These covered a broad spectrum of opinions from optimistic to highly pessimistic.

So where does social media fit in with Product Management?  Recently the folks at Brainmates shared the results of a panel discussion they hosted on the challenges and opportunities that social media poses for product managers and marketers.  There are some great points (that I won’t rehash here), and I’d recommend checking out the post.  Instead of discussing social media and Product Management in general, I’d like to focus in on social media and product launches.  Here are a few considerations that come to mind:

• Planning: how does social media play into your product launch plan?  For example, will you use any social media channels to discuss the launch (blogs/videos/forums/groups/micromedia/etc.)?

• Feedback: along with client visits, conferences, phone calls, and email, social media is another venue to connect with your user community.  While your feedback strategy may vary depending on how mainstream or niche your product offering is, social media can be a source for immediate feedback on your product launch.

• Engagement: Measuring feedback is great when you have an online community, but what do you do when that community starts reaching out to you?  What if your customers hate your new product or update?  Adding social media to your launch plan translates into engaging with your community.  So what does that mean?  Twitter isn’t an RSS feed for your product updates – use it (and other channels) to engage in discussions, thank your community, and open up new lines of communication into your organization.

Circling back to the question about where social media fits into product launch strategy: what can a well-executed strategy look like?  The Social Media Examiner recently authored a post on Cisco’s social media launch strategy.  While cost savings may not be a measurable outcome in all cases, it does highlight the broad spectrum of social media channels a launch can inhabit.  Getting back to the original question posed by the Pragmatic Marketing survey: is social media impacting your launch strategy?

Photo Courtesy of Kryten

A few weeks ago I had the good fortune on going on my first customer tour in quite a while.  I’ve done a lot of these over the years, but it is a refreshing eye-opener to meet customers for the first time in a new role.  While phone calls and email discussions are valuable, there’s no substitute for learning about how customers are interacting with your product.  I want to touch on a few key areas that live visits have helped me with, namely context, feedback, and insights.

A useful component of an in-person visit is an understanding of context.  For example, during the recent trip I was able to visit major corporations along with small and medium-sized businesses.  The needs between organizations of these sizes can vary greatly, and on-site visits can help understand how barriers to success can differ between organizations of varying size.  For example, a large enterprise deployment may require a comprehensive plan for user adoption, initial training, and continuing refreshing (e.g. new features or workshops to get new employees up to speed quickly).  There may also be several groups within an organization that have different needs, and may need to use the system in different ways.  This can differ from a smaller organizations, where the number of use cases may not be as broad and the business needs for the software can be fulfilled by small number of power users.

Feedback and insights are also valuable reasons for customer visits.  Here are a few considerations:

• How are customers using the software (actually watch)?  There’s no replacement for seeing how people interact with software first-hand, as it may not be in ways you would expect.
• Points of pain: are there any “but if it only did this….” moments?
• Learn about the role your software plays at a customer site: how does it add value to their business?  What problems does it solve for them?  What are the usage patterns (e.g. casual usage, project based, constant part of a key workflow, etc).
• Ideas generation: great ideas can come from listening and brainstorming with customers.
• Communications: how is the relationship between the customer and your organization.  Are they getting the level of service they desire?  Are they getting timely updates about new features?  Visits are an opportunity to learn how customers want to interact with your organization.

While events such as trade shows, workshops, and seminars are also great places to interact with customers, going on-site and understanding the full experience through a customer’s eyes can provide a great deal of value.  There’s also another great reason for customer tours: relationships.  Much like we (product management) appreciate feedback, customers tend to appreciate all the software tips, ideas, and insights into the software that you can provide them.  And when you’re not there to sell anything to them, the trust factor can be high.

Now that 2010 has arrived, press releases and announcements for new “2010″ and “10″ version numbers are appearing with increasing frequency.

Why the change?  Why didn’t we see “2007″ version numbers a few years ago?  While there are a lot of 2010 versions coming out, an excellent post on “The Amazing World of Version Numbers” suggests the trend started way back in 1966 with Fortran 66 (although there are even earlier suggestions in the comments).  However, it didn’t register as a common naming practice until the release of Windows 95.

There are many methodologies for software version numbers.  Most of them operate under the premise that a big jump indicates a major release (e.g. moving from 8.0 to 9.0) while a minor increment indicates a minor release or perhaps even a maintenance release (e.g. 9.0 to 9.1).

The connotations surrounding “2010″ are plentiful: a new year, a new decade, and hopefully a new start after the biggest economic crisis of our time.  It’s an attractive reason to switch from an ordered number system to a date-based system.  It also represents a shift from engineering-based ordering to a marketing-based system.  While a 2010 label may give a product a fresh look, vendors switching to a date-based method should ensure the release matches expectations in terms of value for customers.  A minor update with little value repackaged as a “2010 Edition” has the potential to impact brand credibility.  On the flip-side, a new release packed full of valuable capabilities can warrant such a change and deliver some extra oomph during a new release launch.  Like many product management decisions, software version methodologies deserve careful consideration when planning a release.

Image Credit: Marcin Wichary

Most software vendors know that pricing can be a complex beast to tackle.  There are so many strategies and perspectives on pricing that you could fill a book.  Wait a second, there ARE books on pricing…  I recently came across “Software Product Management and Pricing” and gave it a read.  The latter part of the book has some valuable insights, and I particularly liked this one:

“Customer expectations must also be managed: it makes economic sense for a vendor to sacrifice some growth for a longer term commitment; it makes no sense for a vendor to cut price for a renewal of business with no growth.”

The quote pertains to enterprise offerings, where the authors discuss special bids for large accounts.  The point is that price negotiation and discounting strategies should take the larger context of the business relationship into consideration.  Sacrificing long-term revenue for short-term gain is something that happens all the time.  While it may help with quarterly results, it rarely pays off in the long run.

Full reference: Kittlaus, Hans-Bernd, and Peter Clough. Software Product Management and Pricing. Springer-Verlag New York Inc, 2009. Print.

In yesterday’s post I outlined a few thoughts on how product launch processes vary between desktop and SaaS environments.  In writing the post, I noticed that there’s a massive volume of information available online pertaining to product launch planning.  Checking out several of the results, it seems like there are a lot of guidelines – and that’s a good thing.  Guidelines are great to follow, but the reality is that routinely following a checklist for software launches can get you into a rut quickly.  Every release is unique, and treating them as such at the start of the planning process can lead to better results.

Several years back I ran through the gamut of Product Management courses from Pragmatic Marketing.  As a new PM, they helped shape my views on the subject and as a consequence I still try to keep up with their newer material.  With regards to launches, I couldn’t put it better than Dave Daniels did in his “Ten Ways to Identify an Impending Product Launch Disaster” webinar.  Check out the webinar yourself, or the e-book below.  It definitely beats slogging through a lot of search results you’ll find online…

“Ten Ways to Identify an Impending Product Launch Disaster”

Planning software launches is a core element of Product Management, and typically requires a great deal of planning and preparation.  There many opinions on launch planning and instead of covering such a broad topic, I thought it would be interesting to write a few observations on differences between desktop software launches and software as a service (SaaS) releases.

Desktop software release cycles can be lengthy, and the QA and Acceptance Testing planning can be a challenge.  Operating systems, compatibility with other desktop software packages, as well as any proprietary format testing are all major considerations .  The time between major releases could be up to a year for products that I’ve been involved with, which may be interspersed with one or two minor releases.  Because of the lengthy release cycle, it always felt like there was a lot riding on a successful major release: when a year of effort is at stake you want to minimize the risks and ensure the launch delivery is smooth and successful.

With SaaS releases, the fundamentals of Product Management remain the same but the delivery mechanism is quite a bit different.  Here are a few observations, along with thoughts on how they can impact PMs:

Frequency: One characteristic of SaaS is a comparatively fast release cycle: any given individual release may not be as feature-rich, but significant releases may come every few weeks instead of every 6-12 months.  This means that launch plan components which used to be relatively sporadic need to be happening on an ongoing basis.  For example, a communication pipeline to sales teams, partners, and ultimately customers is something that needs to be revisited with a higher frequency.  For distributed teams, conducting internal webinars instead of or in addition to traditional events (e.g. in-person sales enablement training at an annual internal sales meeting) might be a practical method of delivering updates.

Quality Assurance: One of the perks of SaaS is the QA process, since operating system support is much less of a drain on velocity. Instead of having to corral beta customers on different operating systems and worrying about how your test matrix is exploding, you can focus on the fundamentals.  SaaS systems have different sorts of challenges (e.g. you don’t have to worry about up-time reporting in a desktop environment), but the ability to focus on core testing rather than running the same tests on X number of operating systems is a nice benefit.

Delivery:  Depending on the installation footprint, a lot of desktop packages need to be shipped out via DVD.  This represents planning, costs (and ensuring you get your quantity estimates right!), and an extra 4-6 weeks (shipping time) before customers can get their hands on the software.  This entire step is eliminated with SaaS, and from a user’s perspective the new features simply appear in the software upon release.  This presents a unique challenge…  Unlike the desktop software environment, customers cannot simply uninstall a shoddy release.  So the pressure for quality is high in a SaaS environment.  Any critical bugs that slipped through the cracks need to be dealt with immediately – but on the upshot deploying fixes is easier: they can be pushed out to all users at once.  This highlights on of the nice factors in delivery and customer care: when diagnosing an issue, you don’t need to query the customer on what version and patches they have installed and attempt to “find a needle in the haystack” of what could be causing a conflict.  All of your customers will be using the exact same version…

Marketing / Communication: Since SaaS users do not have to manually install new releases themselves, it’s important to think about communication.  I think the ideal is delivering an in-application notification system, but other channels such as blogging, email notifications, or direct contact by account managers are all viable options.  The challenge in the early feature planning is to ensure that new updates improve user experience and do not break or inhibit any existing workflows.

Documentation: A consideration here is that a traditional User Manual, training docs and other materials may become outdated rapidly or a burden to produce due to frequent release cycles.  I don’t have a silver bullet for this one, but I believe a positive direction would be a framework that allows you to plug in new material without a lot of overhead.  In practical terms this could mean digital documentation as opposed to print, and perhaps use of alternate mediums such as video content and short, concise quick reference guides instead of verbose documentation.  I’m definitely interested in other thoughts out there on this topic.

I’m enthusiastic about Product Management in a SaaS environment, and these are just a few initial observations.  Overall it seems to me like the principles of Product Management between SaaS and desktop products are quite similar, but timing and certain tactics can be different…

I’m very interested in insights and opinions on the topic: are there other considerations as well?