It's rare that we post non-business stuff on our blog. I also realize this is a local event. We are making an exception to announce the Haiti Tweetup to help raise money for disaster relief efforts. This fundraising get-together will be held next Tuesday January 19th at 5:30pm at Casa de Popolo in Mile-end Montreal.
See all the details and RSVP here: http://haititweetup.eventbrite.com/
Tickets are free but we ask that people donate at least $10 at the door. All proceeds will go to the International Red Cross (http://www.icrc.org/) who are already on the ground in Haiti and have been for quite some time. If you can't make it, please just donate directly to the organization of your choice.
Help spread the word using #haititweetup on Twitter. Look for the Facebook event called "Haiti Tweetup Montreal".
BIG thank you to the team at Flow Ventures and the group of volunteers supporting this amazing initiative.
B.
First off, Happy New Year to all my friends, colleagues and fellow product managers. Today is likely your first day back in the office and if you are like me (and only now that you are actually in the office), you are super excited about the year ahead. Somehow between turkey legs, Mom's stuffing and New Year's Eve champagne, your product road map magically came together (maybe there really is a Santa (then again, where was he for my last product release!)).
Super charged and ready to go --- I decided to start my day with a list of 10 product management resolutions. Essentially, 10 commitments that I hope will not only make me to be a better product manager but also contribute more value to the company. Here is my list...
In 2010 I will....
- Say "no" more often (twice as many times)
- Take a vacation (a real one)
- Visit more customers (twice as many)
- Apply Win/Loss Analysis (consistently throughout the year --- not just when there's a problem)
- Have lunch more often (and remember to chew my food!)
- Reach out to key managers (no agenda --- just nurture the relationship)
- Thank the sales team (ouch --- that hurts!)
- Read more (at least one book per quarter)
- Get involved (PM Groups, ProductCamps, Associations, etc.)
- Keep my backlog prioritized for at least 2 iterations
Take the stairs rather than the elevator (maybe next year :))
While I'm sure many apply to you as well, I'm also certain you have several of your own. What's on your list? Please respond or comment with your product management resolutions. In return, I will manage a master list and follow-up with you in June --- I promise! Good luck!
Prioritization is essential for product managers because we seemingly work in a world where time is limited and demands are ostensibly unlimited. Our prioritization skills help us spend our time and resources wisely, freeing ourselves and team from less important tasks that evidently can be pushed out - or quietly dropped (isn't it funny how that happens). 
In my last post, High, Medium & Low Don't Work for Agile, I suggested that traditional methods of product management prioritization, for example, P1, P2 and P3s, do both product managers and product teams, a disfavor. Such prioritization approaches do not link backlogs objectively to market demand nor profitability. When resources (time and money) are as scarce as they are, the risks are of not doing so are simply too great.
This week, my objective is to share our scoring and prioritization methodology in hopes of exposing its vulnerabilities. (disclosure: we develop, market and sell a product management platform designed to capture customer feedback, groom and prioritize your backlog). I'm looking to you, fellow product management practitioners, for feedback on how to improve it. Lastly, I hope our discussion (and if enough people are listening) will help others along the way (if so, please let us know who you are!).
To begin, I'd like to distinguish scoring from prioritizing. While they may seem interchangeable, they are, at least in our minds, very different. In this context, scoring is the process of objectively evaluating a specific item (e.g., backlog item or feature) against set criteria. The result of the exercise provides a score that can be used to sort and compare relative value. Items that score well are deemed more valuable.
On the other hand, prioritization is the process of evaluating the scored backlog to identify sequencing and/or sub-sequencing. A prioritized backlog depicts the ultimate order, be it a sequence or a series of sets (buckets), that will deliver the greatest value (superior ROI) in the least time.
Scoring, Prioritization and Sprint Readiness
Prioritization for us is a 3-step process. First, we score our backlog against business criteria (value). Second, we consider technical elements. Lastly, we select a subset of these items which is subsequently our release and sprint backlog (i.e., we iterate and release every month).
1. It's our contention that scoring features against business criteria is paramount and should be the focus of product management. To facilitate this activity, we use and evaluate each item against the following criteria:
- Market Evidence (traceable support from customers/market)
- Stakeholder or Persona Alignment (buyers, users, partners, etc.)
- Strategy Alignment (markets, technology, etc.)
- Business Impact (profitability - increase revenue, decrease cost, both)
It should be noted that our approach has evolved considerably since our early days. Similarly, I suspect you and your organization, like ours, continues to evolve and refine its methodologies. How do you measure business value today? How is your approach different?
2. While it is possible to prioritize features on business merits alone, it's not enough to drive release or sprint planning. Before ideas can be prioritized, they must first be estimated (roughly) by development. Our next step is to add technical attributes.
- Estimate (measurement of size/complexity)
- Risk (the probability or likelihood that the item won't be completed as designed or desired)
- Skill set (PM, UI, DBA, TW, BA, QA, Architect, etc.)
Note, the above technical items don't influence the score, but rather provide additional context to support prioritization, sprint and resource planning. This is a distinct step because it requires collaboration outside product management and with development. Armed with business context (score) and an estimate (hours or story points), we now have the main elements to prioritize our backlog to deliver maximum customer value.
3. The next step is release/sprint planning (remember, we release every month). Given that we now have relative estimates from development, we have all the necessary information to make informed decisions to drive business results. Interestingly, some items may be very valuable to the organization but may take weeks to develop. On the other hand, other requests may be half as valuable but may only take hours to deliver. From experience, this happens more often than you think. Evidently, estimates (costs) influence priority.
Note, we have some customers that use to apply estimates first, that is, before scoring for business value. When we dug into the reasoning, we found it was usually because they didn't have a formal approach to define and score business value. Our position is that you should score for business value first for two reasons:
- Business value should be your primary motivation
- Although your time is very precious, is not as expense as a team of developers cramped in a meeting room estimating or planning poker.
Rather than have developers waste time evaluating items that may never be necessary or "bubble-up to the top", we provide development with a backlog that has already been scored against business criteria. In doing this, we ensure they are working on the most important items first.
To conclude, prioritization is a key product management skill to make the best use of your time and that of your team. Backlogs are prioritized by product management but with the help and collaboration of development. With every release, our goal is to identify and prioritize the backlog items in a manner that produces the most customer and business value.
In my next post, I will dissect each of the above business criteria. I am very interested to learn what you do to prioritize your backlog. For example, do you use story points (e.g., Fibonacci), T-shirt sizes, or actual time (hours, days, etc.) to estimate your backlog? I'm also curious to know if skill set impacts your prioritization. Finally, and assuming you prioritize your backlog for business value, do you share your evidence with development? If so, how do they react?
Based on field discussions and my recent experience at ProductCamp Toronto, it appears most product managers have no formal methodology to score or rank customer feedback or feature requests. In fact, I suspect very few product managers actually score features against any relevant business criteria --- rather they simply apply a basic prioritization scale, for example, P1, P2, P3 or High, Medium and Low. Is this you? For these PMs, spreadsheets are usually the weapon of choice and are commonly initiated with each roadmap, release or sprint exercise. With every new prioritization, a new spreadsheet gets created, copied, revised and versioned --- over and over again. Sound familiar?
What evidently happens with these methods is that P1s 
(or Highs) become disproportionally represented. For example, on 50 features, poor prioritization will result is 30-40 P1s. Of course, in realty, this means nothing. Essentially, it amounts to an abdication of responsibility --- responsibility for making a product management decision.
As experienced product managers, we all know, "if we don't do our jobs ---someone else will". In this case, it's likely to default back to development. Note, developers make decisions based on technical fun factors --- and they don't consider UI to be fun, ever. Hmmm... I think I'd rather get my teeth pulled...
Few Product Managers Apply Business Attributes to their Backlog
Not sure why, but I imagine lack of training and tools have a lot to do with it. This is particularly disheartening because both are available online --- either for free or very affordable.
The problem with this approach, I believe, lies in its simplicity. Don't get me wrong, simple is good --- but only if it's effective and drives intended results. Truth be told, I'd like to think product management today is a little more sophisticated, intelligent and strategic. I'm curious, if you are a product manager that uses one of the aforementioned prioritization methodologies --- I'd like to hear from you. Specifically, what drives your decision making? What makes one item a P1 and not a P2? How does a simple ranking demonstrate or communicate your strategic objectives, be it short or long term?
The biggest issue with a simple priority system is that it neither supports nor encourages the product team to think strategically. Must Haves, Should Haves and Nice to Haves are fuelled by opinion and filled with conjecture. How does High/Medium/Low demonstrate value or congruency with product objectives? As product managers, aren't we always defending our strategic value? Isn't this an ideal opportunity to demonstrate our business aptitude and strategic thinking?
Problem is Amplified with Agile
Perhaps my position is skewed as an Agile (SCRUM) practitioner and advocate. In fact, I see this issue amplified in an Agile environment. How do P1s, P2s etc. support sprint planning? What do you tell development --- do all the P1s? How do they know where to start or focus?
Aren't we supposed to have a theme or goal at the root of each sprint? If so, how are these objectives reflected and supported in your backlog? The onus is on us. If Product Managers or Product Owners don't step up and effectively control and prioritize their backlog, the team will flounder, lose valuable velocity and become increasingly frustrated.
Certainly, I have some ideas to address this issue and will address them in a follow-up post. In the interim, I'd like to hear from you and learn about your prioritization practices. Are my assumptions way-off? Am I complicating a simple task? Trying to kill and ant with a bazooka?
In start-ups, it's not uncommon for the initial idea to come from the founders own industry or domain experience. This works well at the beginning --- when start-ups need leadership and credibility. However, one of the biggest mistakes early start-ups can make is wait too long to formalize product management and for the founder to manage product with an iron fist. This moment in the life of a start-up can be very difficult for founders. They have a tendency to believe they "know it all" and are therefore reluctant to secede responsibility to a new hirer or someone "junior". After all, with X years of experience --- who could possibly do a better job?
There are at least three dangers with this scenario --- competency, market dynamics and human nature.
- Most CEOs/founders have no product management training. In fact, very few actually understand product management (role, responsibility, strategic value etc.). Sure they talk a good game (reads lip service) --- only to dismiss product management as "academic".
- Founders are notorious for assuming the role far too long. One, two or three years into the start-up the market has evolved considerably --- yet many founders remain stuck in their old ways, failing to recognize the speed of change or the new market dynamics. As time goes on, founders increasingly become disconnected with reality. Failing to react to this (before it's too late) creates an increasing credibility gap and dampens moral (two poisons that can kill a start-up). The perception among the rank and file is that management (i.e., the founder) is just not "listening". Let the revolution begin...
- Somewhere between day 1 and early market success, founders need to formalize the role and delegate product responsibility. During this period, founders become engulfed with building their business (as they should be), the only problem is unless they create a product management position and allocate responsibility the role of product management will remain unfulfilled --- eventually creating a product vacuum. In reaction, Development, Marketing or Sales, albeit consciously or unconsciously, will vie to assume the product management role (if you don't do it --- someone else will!). Each armed with their own recipe for disaster, the department that wins the product management sweepstakes will own it and set a course influenced by what they evidently know best --- development, marketing, and sales respectively (none of which is a good substitute for product management). These troublesome issues undoubtedly call for dedicated posts...
To conclude, founders should focus on building a sound company, talking care of people and driving the company vision to fruition. They neither have time to visit customers nor the skill to articulate requirements, and the market insight to conceive positioning etc. The sooner they embrace product management and entrust the responsibility --- the better. Failing to address this before it becomes a problem causes start-ups to stagnate or worse yet --- fizzle away.
Last weekend I attended ProductCamp Toronto. As a first timer, I really wasn't sure what to expect. I am delighted to report it was both a great day and event (aside from my travel interruptions courtesy of AC). The event organizers deserve a lot of credit. The facilities, food and refreshments were great. Lee Garrison, Chris Gurney, Chris Herbert, Saeed Khan, Siobhan Mclaughlin, Lea Sawal deserve to be called out.
It was also an event that Quantum Whisper had the privilege on sponsoring. The event had many great sponsors --- and fortunately, still managed to avoid becoming too commercial. In addition to sponsoring ProductCamp, Quantum Whisper also provided a door prize ($100 Amazon gift certificate). Congratulations to Jackie Serviss! Enjoy your shopping!
If you are contemplating attending a ProductCamp in your area --- I urge you to get involved. As a product management professional, it was an exceptional opportunity to mingle with colleagues, network and learn from the tremendous product management talent and experience at the event. Industry gurus attending included Steve Johnson of Pragmatic Marketing, Stewart Rogers from Ryma Technologies (and the strategicproductmanager.com) and Saeed Khan from onproductmangement.net.
Most of the day was spent in various sessions where participants exchanged product management best practices, ideas and experiences. I facilitated a discussion on product management tools. The event schedule is below complete with session notes. Let me know if you have any follow-up questions.
Looking forward to my next ProductCamp --- maybe Boston?
Is anyone attending ProductCamp Toronto? If you are, please take a moment to introduce yourself.
Incidentally, Quantum Whisper is pleased to announce sponsorship for ProductCamp Toronto. The event, scheduled October 4, 2009, will be held at the Ted Rogers School of Management, Ryerson University.
ProductCamp is a great opportunity for participants to learn from, teach to, and network with professionals involved in Product Management, Marketing, and Development.
Interested in attending --- register at http://www.productcamp.org/toronto/register/
Looking forward to a great day and great event.
See you there!
Earlier this summer, the
280 Group and
Quantum Whisper teamed-up to complete an extensive
product management survey. First and foremost, we were delighted with the community response and the approximately 800 participants --- THANK YOU! As for next year, we hope to build on this year's edition by integrating your feedback.
The product management survey results are available in two formats:
- On-line: Featuring the entire survey, the online version is immediately available for viewing and includes a comment area (ideally suited for questions and community discussion).
- PDF: A downloadable PDF is available for those that prefer a local copy.
Below are just some of the highlights:
- 78% of product managers work weekends (average 6 hours)
- The average product manager is responsible for 3.3 products
- 33% of respondents indicated they will not offer software-as-a-service (SaaS)
- 38% practice agile development (e.g., SCRUM)
- 4.5 is the number of average product releases per year
- Only 22% of those that use product management software "love it".
- Only 6% of respondents rate the quality of their "market evidence" as "excellent".
Product Management Survey Link
Please, don't forget to share your feedback!
Enjoy!
In recent years, the software industry has transformed itself. SaaS adoption is wide spread and is now a credible business model. Looking beyond Salesforce.com, other companies like Concur, Vocus and RightNow are successful (reads profitable) as well. The advent of SaaS has left many antiquated companies like SAP and Microsoft struggling to adapt. Interestingly (and a topic for another post), others like Lawson's CEO, Harry Debes, believes SaaS is doomed to collapse. Regardless of where you stand, the reality is that many companies are practicing SaaS and there are thousands of SaaS product managers that are similarly struggling to adjust. Making matters worse, is the product management industry has been equally slow to adapt and provide new guidance or practices.
I'm not sure why, but many product management evangelist and training companies have yet to address the impact of SaaS on product management. At least one leading consulting firm in the field minimizes SaaS to a mere delivery model, suggesting product management is "business as usual". In doing so, they reinforce traditional practices --- ignoring the obvious nuances of SaaS. Perhaps it's been too long since these "gurus" have been product managers themselves. Staying connected has always been a challenge for consultants... (I should know, I am one).
Below are a few points illustrating how the industry is changing and a sampling of how product management responsibilities and skills are evolving under SaaS.
- Market Intelligence: Traditional product managers make client calls, win/loss reports and customer visits. For product managers, this is a primary source of market intelligence. It is these activities that allow them to observe customers and understand business problems. This approach has historically been product management "best practice". But how practical are they for SaaS companies? With 1000's of customers rather than dozens or hundreds, SaaS product managers can't possibly call or visit enough customers to return any statically relevant data.
SaaS Approach - To address this problem, software product managers will turn to on-line communities. Pressure to keep cost down, increased user influence and an attempt to increase customer value (overall experience) are some of the more obvious factors that will drive this initiative. Product based communities will drive product direction and development and force product managers to adapt their techniques and skills for the new paradigm.
- Pricing: Gone are the days of 90% margins and basic P&Ls.
SaaS Approach - SaaS product managers must now become intimately familiar with pro forma statements and product BOMs, more specifically, fixed vs. variable cost. What is the cost of a single new customer? How do I integrate computing consumption into my pricing? What is the total cost to service a customer? How many customers do we need and when can we expect to make a profit? What is my target margin? What is the expected payback period? Two, three or four years? How do I account for the marketing ramp-up, new sales commissions, and support (the old days of X % of license price are over!)?
Perhaps is time to add management accounting (advanced) to the list of product management skills.
- Packaging and Fulfillment: Do I want a single offering and a single price? It worked before --- right? But now that we are targeting volume (i.e., customer acquisition), how do I accommodate the less sophisticated and budget sensitive customers? How do I simplify my offering, provide enough business value to warrant subscription costs and simultaneously preserve value for more sophisticated customers?
Historically, software product management addressed these concerns with "lite, professional" and "enterprise" applications (remember "standard" and "basic" versions... I have yet to meet anyone that wants to buy anything standard or basic). In most instances, each version was a code branch with a set of features turned on or off. Over time, they increasingly became distinct products. Some even eventually needed full-time product managers.
SaaS Approach - Today, these customer segments (and more) are addressed in a single code base. Customers are free to upgrade or down grade almost at will. To manage these requests and to minimize the overhead (fulfillment, billing etc.), SaaS product managers need to consider new fulfillment (on-boarding) tools (e.g., OpSource and Aria) to provide this flexibility but also to enhance customer experience. While you still have to determine the feature set for each version, you can minimize the transition and switching costs.
- Change Agents: Unless you are one of the fortunate product managers that is employed by a company that was conceived with SaaS from day one, you will evidently be challenged to align your organization to the new on-demand model and subsequent culture required to sustain it (see my earlier post, "Shifting from Product to SaaS" for tips on how to get senior management on board). Although it may appear counter intuitive, the application development is actually the easy part. It's getting the rest of the organization in-line that is demanding. Unless the organization adjusts, the promise of on-demand will elude both you and your customers.
No doubt, companies that are introducing SaaS are building solid applications. What escapes most of these organizations are the skills and systems required to support the service model. Many fail because they conduct sales, marketing, support, services, and finance using the same tools and resources used to support traditional grounded software. Takes Sales & Marketing for example, many continue to practice direct marketing, print ads, customer visits, trade shows, etc. While these activities do have a positive influence on sales, the issue lies in their cost. Scaling these activities is simply not congruent with the SaaS business model.
In an effort to call out some nuances, below are a few examples how SaaS touches every department.
SaaS Approach
-
Product Management
- Thought leadership
- Serial releases - requires increased communication (inside and out)
- Smaller iterations - constant prioritization
- Customer (community) feedback - product requests, self-service, and best practices
-
Marketing
-
Continuous marketing with constant up-sell and cross-sell
-
Touch users early, often with business relevant information
-
Marketing targets new and existing customers
-
Provides services throughout the organization
- Sales
- Low cost, higher volume sales model (e.g., on-line)
- Shorter sales cycles with increased focus on business relevance
- Compensation (what happened to my big fat check?)
- Services
- Setup, installation and upgrades are no longer the focus of services
- More business consulting and education versus technical implementation
- Support
- Support provides as a critical touch point that requires and experienced skill set
- Switch to a true 24x7 multi-channel support
- Shift from issue resolution (break-fix) to ensuring ongoing customer success
- Balance need for higher-volume, lower cost to serve
- Customer monitoring and subsequent coaching becomes strategic
- Finance
- Revenue recognition, financial system for tracking deferred revenue
- Billing systems with tiered products, metering service levels, and managing renewals
- Engineering
- Architected for multi-tenancy and high scalability
- Infrastructure to support tier management, customer metering, service levels, retention policies, and self-configuration
- Agile to support faster release cycles
To conclude, fundamentally the role of product management hasn't changed but the nature of the job is absolutely evolving. SaaS product managers face different challenges and must adopt new tools and allocate their time wisely and efficiently. SaaS companies must use technology to drive automation, reduce cost and increase customer self-service. Product managers must deliver applications that scale with volume but maintain fixed cost and overhead. As a SaaS product manager, your service offering permeates the entire organization. Be prepared to lead --- if you don't, it's likely no one else will.
I suspect many software product managers have already experienced introducing a SaaS offering to either replace or complement existing solutions. I also suspect that many more are either considering doing so or are currently engulfed in the complex and difficult transition period.
If you are a product manager making the shift, the transition period is probably the toughest career challenge you will face. Unless your company was founded with a SaaS model from the start, adopting a service model suggests you will have to reengineer, retool and retrain the entire company. I think everyone will agree (PMs - please remove your capes for a moment), this mandate goes beyond a product manager's scope of responsibility. As a thought leader and market expert, product managers can map out a strategic path, a go-to-market strategy and a service that delivers great customer value --- but unless the rest of the company is on board and behaving like a service company --- the likelihood of either you or your company succeeding is almost zero. No, it is zero.
The crux of the problem is getting your company's cost structure in-line with the new business model. Armed with influence and a magic wand that seldom works, product managers are not empowered to drive this vision to fruition. So, how can a product manager help?
- Do your homework. The SaaS buzz continues to grow --- but it's not for every company or solution. Your solution may be too complex, service intensive or your target market may not be homogeneous enough to support the model. If you haven't already, build a business case complete with pro forma financials. Is the grass still greener on the other side?
- Have a discussion with your top executive. Explain the nuances and challenges the new model presents. No need for a deep dive --- focus on ensuring that your total cost of service (TCS) is less than the lifetime value of a customer. Consider a healthy margin and you have the dynamics to drive home your point. Just make sure they don't misunderstand aligning cost with a chainsaw and a deep round of layoffs. This is less about headcount and more about fostering a service orientated culture and providing the systems and skills to support it.
- Point out the risks and opportunity cost of not taking decisive action. Increased time to market, a narrowing market opportunity, and a rapidly decreasing run-way are good examples. Without an acceptable cost structure, a value added service engine and a sales and marketing strategy to match --- you may find that each new customer is actually costing more money than they contribute.
- Provide thought provoking articles, blogs, etc. that address the topic head on. Here is one example:
SaaS Competitive Advantage - SaaS Economics 101 e-Book http://chaotic-flow.com/2009/05/04/saas-competitive-advantage-saas-economics-101-e-book/
- Repeat steps 1-5.
Given the scope of change required and the potentially deep and disruptive impact on the business, it's imperative that your SaaS initiative have absolute support from the corner office. The vision, leadership and message must come from the top down. It's not enough to control cost alone. You will need the infrastructure and behavior to perpetuate the model. Evidently, tough decisions will have to be made and not everything or everyone will survive.
Finally, if after several attempts to outline the intricacies of the business SaaS model, your actions are being politely dismissed or commitment is wavering --- you have two options. Update your resume and take your game to a company that "gets-it" or stick around and wait to be fired. When the product (service) fails miserably ---- you'll be the scapegoat.