Category Archives: Product Roadmap

Planning and Launching Software Products in an Agile Environment

This week, I had the opportunity to speak in the Agile Practitioners 2013 conference. The topic of the talk was Product Roadmap, Planning and Launch in an Agile Environment.

The talk was around approaches to modern product management, and specifically considerations due to agile methodologies and short product release cycles.

Fundamentally, old-style product management assumed software releases are done infrequently, something along the lines of this diagram:

 old-style-cycles

Whereas modern product cycles rely on shorter cycles, something along the lines of this diagram:

 modern-cycles

The assumption in modern approaches is that the road to good software is shorter when making smaller steps and frequent turns than when making large steps and more radical turns. (This is geometrically true in the diagrams…)

Old-style product cycles consisted of three main steps: planning (negotiation, prioritization, scheduling), development (design, coding, testing) and launch (alpha/beta, release, outbound marketing). The main question I was trying to tackle in the talk was how the corresponding activities map to product cycles with frequent releases.

On a side note, some organizations use old-style product cycles (infrequent software releases) while using “agile development” techniques internally (that is, frequent internal releases). While perhaps better than nothing at all, this approach misses—in my mind—much of the benefit in agile software development. In the end of the day, the biggest benefit is adapting to customer feedback, and without the software reaching real customers, value diminishes.

The areas I was trying to tackle in the talk were:

  • How does planning occur in an environment when there’s no defined period for planning (“beginning of the release”)? When the working assumption is that many of the details (and associated effort) will be revealed during the development process. And, how do roadmaps look in such an environment?
  • How do product launches occur in an environment when there’s no defined period for launch, but—instead—software is ready in chunks? How and when does customer feedback get incorporated into the cycle?
  • How does one integrate new approaches and opportunities brought about by agile development? Mostly, agile approaches facilitate experimentation through proof-of-concepts and such (with various variants such as MVP, MSP, and lean).

Here are some of the practices we’ve come to follow over the years:

Continue reading

Advertisements

Product Planning in an Agile Environment – Talk @ Agile Practitioners 2013 Conference

In case you’re in the Tel Aviv area on Jan. 30, 2013, you’re most welcome to drop by the Agile Practitioners 2013 conference. I plan to deliver a talk titled Product Roadmap, Planning and Launch in an Agile Environment.

The talk will revolve around the fact that in an Agile environment, predictability is knowingly sacrificed for flexibility. Agile practitioners assume that what’s being development changes along the way, and that the true effort associated with each new development is only revealed during the development process. They  knowingly release new product functions in smaller chunks. And, they empower individuals and let them drive the process. This essentially makes traditional approaches for managing product roadmaps and launches obsolete.

I plan to cover some approaches and techniques in managing a product in an Agile environment, highlighting some examples from our experience at Webcollage, delivering a SaaS product to a large number of high-profile customers. The current plan is to touch various angles of the conflict, from planning (internal vs. external roadmaps, hard vs. soft commitments), conflict resolution (emergency and time-sensitive issues), release and rollout management (soft vs. official launches, gradual rollout, alpha/beta cycle and feedback management), as well as some additional areas as time allows (documentation).

 

Why (Direct) Democracy is bad for Software Products

It seems that more and more software vendors rely on user feedback tools and forums (such as UserVoice, which I mentioned in a previous post). The thought, in many cases, is that user votes can drive the product development roadmap in a way that resembles democratic elections: the more users vote for a feature, the faster it gets addressed. Some tools even allocate a limited amount of tokens for users and let them distribute the tokens across feature requests.

This thought process quickly translates to communication with customers. For example, at Webcollage we recently evaluated a software product for our development organization. We quickly noticed that the product did not work in our environment, and contacted the vendor. The response we got was:

“This functionality is not supported in [Product Name] at the moment. However, you can add this suggestion on our forum at [URL].”

A few months ago we received a more annoying response from an otherwise respectable vendor, whose software (during our evaluation) did not work as expected in Internet Explorer 8:

“It looks as though we also do not recommend the use of Internet Explorer 8 and under with [Product Name] in general. If IE8 is a requirement for your development team(s), please be sure to comment on and vote up the issue I’ve linked above. Please let us know if you have any other questions.”

Such a response misses the mark in almost every possible way, from customer relationship management (if a customer is evaluating your software, do you really expect them to take the time to vote up bugs?) through product positioning and documentation (you either support Internet Explorer 8 or not; if you do—please fix issues; if you don’t, that’s fine—don’t include it in the list of supported browsers), product planning (are you really relying on frustrated customers to drive your browser support strategy?), through simple business sense (do you really count feedback from all customers in the same way, regardless of their level of use of your software, level of savvy and their business potential?).

It seems to me that this approach is derived from fundamental lack of understanding of democracy, and why direct democracy hasn’t survived.

Continue reading

Care to be Knighted? Design Your Software Right!

Care to be Knighted?In case you’ve missed this monumental event, Apple designer Jonathan Ive was knighted last week by the Princess Royal at Buckingham Palace.

Indeed, Apple (with Jonathan Ive’s dominant participation) has revolutionized how consumer electronics products are designed. Starting with its color iMacs, which introduced color as an important buying criteria into the mainstream consumer electronics market, and later (as discussed ad nauseam) with its iPods, iPhone and iPad products, Apple has led the market with respect to how products are designed.

In the non-software world, product design has been acknowledged to be a vital part of product success. Industrial design has become a profession, driving product design in multiple industries. Furniture company IKEA has grown based on offering “highly designed” (and arguably, mediocre quality) furniture. Sodastream, a publicly traded $700m maker of home carbonation products, has started growing after putting focus on product design.

When it comes to software, however, there isn’t even a well-defined role, position, or step in the process that addresses the full spectrum of product design. Continue reading

Developing SaaS? Forget Scrum, Check Out Kanban and Similar Approaches

Earlier this week I’ve had a chance to present WebCollage’s agile development methodology at a local Agile Practitioners meeting.

At WebCollage, we are releasing a new version of our SaaS based solution to our customers every two weeks. We released 23 versions in 2011, and will be releasing the 6th version of our software over this upcoming weekend. In other words, we are firm believers in agile development and in its ability to help obtain continuous market feedback (here’s a previous post on this topic).

For various reasons, though, agile development has become somewhat synonymous with one specific approach, namely Scrum. Realizing that Scrum is widely accepted, I previously expressed an opinion that Scrum is perhaps an interesting recipe, but is far from being the best approach to SaaS agile development (and web application development in general). I have received quite a lot of feedback on that other post, some with contrarian views arguing that Scrum is perhaps a silver bullet after all.

There’s always something to be said for using the most popular approach. As an old IT saying goes, no one ever got fired for buying IBM. In this regard, there are intrinsic advantages to using Scrum, most notably the industry ecosystem: ability to easily find knowledge, share best practices, etc.

Insomuch as the actual methodology goes, though, there are simply better alternatives for many software development scenarios. Here’s a sketch of how we at WebCollage develop software, and the advantages it has over Scrum. Our approach is an adaptation of Kanban/Lean software development.

Continue reading

7 Ways to Get First-Time Users to Love Your Web App

I regularly try out new web applications, and I am often amazed to see web applications that assume that a “short introduction video” will get users to understand what the product does and how to use it.

Sure, people love videos, and watch tons of funny cat videos. But, application tutorials aren’t funny cat videos, at least in most cases. For one thing, especially if you’re marketing a SaaS application to business users, it’s likely that users don’t even have headphones connected at their work space; or, similarly, that they doesn’t feel comfortable watching videos with their peers around. As likely, they may want to start using the application right away and may not want to take the time to watch an introduction video. But, most importantly, a video is just one tool in one’s toolbox, and getting users from point A (say, registered for a free trial) to point Z (they’re the guru of your product and help their peers use it) takes much more than a video.

Earlier this week, we at WebCollage have launched a new revision of our Content Publisher welcome pages, so I thought it may be a good opportunity to share the techniques we’ve come up with in terms of communicating our application functionality to first-time users.

I tried to outline 7 “tools” you can use to get first-time users to understand and hopefully like you web application. Here goes–

Continue reading

Taking a “Product Debt”? Be Ready to Pay Interest

Last week I attended a conference kindly organized by Outbrain, a start-up company located in Netanya, Israel. Outbrain’s VP R&D, Itai Hochman, described their engineering philosophy, which includes—among other things—avoiding “broken windows”. The Broken Windows Theory (popularized by the decline of crime in New York in the 1990’s) suggests that having broken windows in a neighborhood quickly escalates into more severe crime. The engineering analogy would be that unattended “issues” in the product would similarly result in more global deterioration of quality.

The broken windows metaphor is appealing. But, a metaphor from the economics world—that of a debt—may provide a few more tools to handle product gaps.

In many parts of the world, it is common to take loans to finance large purchases, such as a house or car. Interestingly, most people can typically pretty easily understand the concept of a loan, or debt. There’s the net cost of what you want to buy (say $100,000). Rather than paying the net cost upfront, one pays some down payment (say $20,000), and then pays back the remaining portion in installments over a period of time (say $2,000 monthly). The eventual sum paid incorporates some interest, which means that the overall price paid is higher than the net price. Most people get the concept, and can even handle the math with some basic calculators.

What’s interesting is that when creating software, a similar phenomenon occurs. And, as the recent economic meltdown has proven, taking more debt than one can afford can have a detrimental effect.

Here’s how the analogy works.

Continue reading