The ACCOLADES award program is designed to recognize growing, dynamic and successful companies on the West Island (Montreal). Quantum Whisper, an innovative agile product management software company, is delighted announce its nomination in the small business category. The following is an excerpt from the recent press release annoucement.
"At the prestigious 40 Westt Restaurant, Ms. Joanne D. Photiades, Senior Manager, Business Development Bank of Canada and President of The West Island of Montreal Chamber of Commerce and Mr. Nishant Sharma, Business Development Director, Caisse populaire Desjardins Sainte-Geneviève de Pierrefonds, co-president of the West Island of Montreal Chamber of Commerce Accolades Competition and Gala, announced the 32 finalists who distinguished themselves in the business community.
"The West Island business community has again shown great vitality in various businesses and industries", stated Mr. Éric Léouzon, President of Maestro Communications and President of the Chamber’s Accolades Grand Jury. The candidates included entrepreneurs, SMEs and large businesses and the Grand Jury was very impressed with the quality of the nominations submitted in the 10 categories.
The winners of the competition will be announced at the 2011 Accolades Gala, which will take place on Thursday, May 26th at the Marriott Montreal Airport Hotel."
No one grows up wanting to be a Product Manager. Most of us fall into the role. While you may or may not have a "product manager" at your company --- one thing is for certain, your product is being managed --- the question is by whom? The primary role of a product manager is to be the messenger of the market.
Why ProductCamp Montreal?
We all know Montreal is increasingly becoming recognized for its vibrant start-up scene, highly skilled, creative and multicultural workforce, top research universities and attractive tax incentives. However, despite what amounts to a great environment for prosperity, we (collectively) haven not realized enough success. In short, we are great at building things, sometimes really cool and interesting things; but, we are not particularly skilled at commercializing them.
This notion, coupled with the fact that the product management industry, and especially in technology, is in its infancy (demonstrated by the lack of experienced professionals and a standard body of knowledge), compelled us to introduce ProductCamp Montreal and create a product management community whereby experienced product enthusiasts and the curious alike, could share best practices, experience and network.
Highlights and Agenda
Whether you work for a small 
company or multinational, in manufacturing, web or mobile, all great product managers have a few things in common --- they are passionate about people, problems and building solutions. Moreover, while the products and technology may be different, overwhelmingly the challenges remain the same. In fact, this was evidenced by the 100+ people that gave up an entire Sunday to attend "workshops" and presentations compromised of two tracks, Product Management and Product Marketing.
Alistair Croll kicked-off the event with an excellent keynote entitled, "Cloud, Analytics and Product Management". Alistair is someone that has been through it all and can teach most of us a few lessons. Eight sessions followed with topics that included launch best practices, the differences between product management in large corporations versus startups and customer development.
Organizers & Sponsors
As first time organizers, admittedly, there were times we felt we were in over our heads. However, with the help of a few web-based drills, generous sponsors (Pragmatic Marketing, Ryma Technologies and of couse, Quantum Whisper) and a devoted organizing committee team (Chris Frosztega, Gabriel Obadia, and Thomas Schmidt), the first ProductCamp was held on Nov 21st at Concordia University, courtesy of the SIFE chapter of the university.
It was equally a learning experience for organizers and participants as we now know more about the audience and their interests. It was great to meet like minded people and humbling to see the sheer number of talented people in Montreal. We followed-up ProductCamp with a survey and received several great ideas for the next ProductCamp. Thankfully, this type of feedback provides an excellent foundation for future events.
This never gets boring. Enjoy!
Has this ever happened to you? Share your story. It would be great to learn how you managed to get out of the situation (or maybe you didn't). I'm still chuckling...
Microsoft announced that Quantum Whisper, an emerging startup focused on
customer feedback and agile product management, was named second runner-up of the 2010 Blue Sky Innovation Award. The award recognizes Quantum Whisper for its market-changing approach to solving customer satisfaction and product management challenges, as well as for its innovative use of leading technologies.
The Blue Sky Award rewards companies who break away from conventional processes or go beyond marginal improvements in existing products. The best of these innovations will prove massively disruptive and enjoy infinite potential in the marketplace. Finalists were asked to present their innovative product, along with the market potential and business plan, to a panel of Microsoft and industry experts for judging.
"With the Blue Sky Innovation award, our objective is to encourage Canadian technology innovation. Canadian ISVs are constantly bringing fresh and innovative technologies to market," says Gladstone Grant, Vice President of the Developer & Platform Evangelism, Microsoft Canada.
This is the first major award for Quantum Whisper and is a monumental achievement for the 18-month old startup. Founded during the peak of the recession, the company is on track to execute against its business plan and experience rapid growth.
"We are delighted to see Quantum Whisper recognized for its innovative feedback and product management solution," says Barry Paquet, CEO and founder, Quantum Whisper. "This award validates our vision, technological innovation and customer value proposition," he continued.
Quantum Whisper provides an online solution that captures customer feedback, transforms data into actionable information and allows product managers to prioritize product requirements supported by market evidence (facts).
Unlike static spreadsheets, the service automatically links feedback to product requirements, providing fact based evidence to drive product decisions. The result ensures the most valuable software is developed and allows product teams to quickly adapt to changing business, market and customer demand. Customers experience reduced product risk, improved competitiveness and increased customer satisfaction.
About Quantum Whisper
Quantum Whisper empowers companies to realize the maximum value from agile development by ensuring that product management is market-driven and that development is prioritized for utmost customer satisfaction and profit. Targeting product managers who are increasingly challenged to maintain prioritized backlogs, simultaneously increase customer intimacy and are frustrated with the lack of simple, affordable and professionally targeted product management tools, Quantum Whisper provides an online service for product managers. It uniquely extends agile principles outside development by establishing a bona fide link between customer demand and product development.
For more information, please visit http://www.quantumwhisper.com/.
Good news! Last month I was notified by Agile 2010 (Orlando, FL August 9-13) that my product management session and speaking proposal was accepted. I am super excited about the opportunity to present. The conference is stacked with dozens of industry experts scheduled to present on various topics ranging from agile adoption to UI/UX design. It should be a great learning and networking opportunity. Dave Thomas (Bedarra Research Lab) and Mike Cohn (Mountain Goat Software) will be keynote speakers. If you aren't already familiar with the event, it's produced by the The Agile Alliance, (www.agilealliance.org) an organization dedicated to promoting the concepts of Agile software development. In its ninth year, the Agile Conference is one of the premier events for the Agile community.
It should be no surprise that my in interest is particularly from the product management perspective. I've blogged in the past about the impact agile is having on product management and especially the new challenges and responsibilities that come with it. Usually Agile is adopted by development and little attention is given to how it impacts the rest of the organization. Product management is usually first to get the wake-up call (more on that later).
Another emerging area of interest that is increasingly important is the notion of "Customer Development". A methodology that is also growing, only in this case, it's coming primarily from the startup community and the lean startup evangelist from Silicon Valley. Steve Blank, an 8 time entrepreneur and university professor, released the framework in his book entitled The Four Steps to the Epiphany. I highly recommend this book for all entrepreneurs, in startups as well as in big companies.
My session, entitled "Product Management, Agile and Customer Development" will illustrate how these disciplines coupled with product development work in parallel to reduce risk and create products that not only resonate with customers --- but also solve a problem customers are willing to pay for.
Session participants can expect an introduction to Customer Development and how the essential roles of Product Management and Agile Development combine to minimize product/market risk. The session will address the following questions and topics:
- Why Product Development Fails Us
- What is Customer Development and Why do We Need it?
- Customer Development vs Product Development
- The Role of Product Management and Agile Development in Customer Development
- How to Synchronize Product Development and Customer Development
Interested in attending? If you are interested in learning more, improving your skills, or sharing your expertise around agile --- Agile 2010 is the place to be! Also, be sure to ping me in advance to set up a one-on-one. See you in Orlando!
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.