Crowdsourcing ideas for Canada’s future

Yesterday, I posted Canada’s Innovation Gap (part 3) where I discussed some ideas for solving the lack of innovation that exists in Canada.

This weekend, the Liberal Party of Canada is hosting a conference in Montreal focusing on Canada’s future.  The conference is called Canada at 150: Rising to the Challenge. It’s a non-partisan conference bringing people from different industries,  political views and areas of Canada together to discuss 5 key challenges related to the nation. Those challenges are:

• Jobs Today and Tomorrow: the Productive Society of 2017
• Real life issues for Canadian families: How do we care?
• Energy, Environment, economy: Growth and Responsibility in 2017
• The Creative and Competitive economy
• A strong presence in the world of 2017: Commerce, values, and relationships

What’s great about this is the relatively open process they’ve used to get the participation from all parts of the country. Clearly with an agenda like this, the topic of innovation was discussed.

The following panel discussion, along with Q&A is well worth watching. Some really frank and honest comments are made.

(click on the image or click here to go to the video. NOTE: The first minute or so is in French and then it moves into an English discussion. )

A great comment from the early part of the discussion came from panelist Roger Martin, Dean of the Rotman School of Management, University of Toronto.  He gives his definition of innovation and invention.

Innovation does not equal invention.  Invention is producer driven. Someone says, I want to have some kind of gadget. And they dream it up in their lab or basement or garage. And it may not be of interest to anyone else. That’s invention.

Innovation is driven from the user or the consumer side…it’s about improving the experience of the end user or consumer.

Note the point that innovation is driven from the user or consumer perspective. It doesn’t mean they drive the innovation, but that their needs must be central to the innovation process.

Later on, when answering a question about the role of taxpayers and the government in helping spur innovation, Martin says quite bluntly:

I made the distinction earlier about invention and innovation. The problem for Canada and it’s been this way for a long time is we don’t have an innovation policy in Canada. Unless you call benign neglect a policy. We have an invention policy and in fact all of our money goes for invention and that’s the gross error.

I love this statement as it’s so straight forward and unapologetic. We need more people like Martin to speak out this way.

I strongly recommend listening to the full discussion. They discuss value of design in new product development, the reasons for lack of commercial success for Canadian “invention”, the sad state of the VC industry in Canada and much more. It’s very honest and in many places quite astute, and I feel, long overdue.

Saeed

Guest Post: Web Product Management 101 for “Offline” Managers

NOTE: The following is a guest post from Thomas Fuchs-Martin. If you feel inspired to write a guest post of your own, click here to find out how to submit it to us.

—–

You are an experienced software product manager and you are thinking about developing your first web product?

Great! This blog post is written especially for you!

Be aware: The fact that you are about to manage a web site really changes a lot in your product strategy and the management processes that you know from “offline” products. I have prepared a crash course for you – defining terms and phrases that you will need to understand as part of your web product management role:

CPC, PPC etc.
Due to the fact that there are many different kinds of business models that exist in the web world, a lot of abbreviations have become very common (I am not really sure if that is a good thing…), particularly when it comes to advertising!

Most common is PPC (Pay per Click) which describes a model where the advertiser is charged only when a user clicks on their ad. Google Adwords is the most well known example of this. The payment amount or CPC (Cost per Click) defines the price paid by the advertiser for each click.

Even if your business model will not be advertising-based, the day will come that you either want to advertise your product on other sites or that you want to implement some advertising model on your site. You will need to understand the common models to avoid (expensive) mistakes.

Emergency Deployment
A website has to be up and running all the time, and there can be numerous backend servers and database needed to do this. You’ll need to schedule regular maintenance time to handle patches and upgrades. But, if you encounter a large bug on your production site or the site is not working at all, you might need to interrupt the usual release cycle and schedule an emergency deploy to fix urgent problems. In the worst case you will have to adjust the timings of your product plan because of these events.

SEO
In “offline” product management you basically have to think about how to create a great user experience. In web product management you have to think about search engines, too. Unfortunately users and crawler bots don´t always have the same needs which makes SEO (search engine optimization) quite interesting. SEO is the process of improving traffic to your site from search engines.

Important: Do not get the idea that you can completely outsource this! The majority of modern internet business models are based on good SEO, and your product planning will be affected by SEO requirements right from the start!

Private Beta / Public Beta
That is possibly one of the biggest luxuries that you will have as a web product manager. You can launch your product while it is still in beta-state. You just put a “beta” label beside your logo and a feedback-button somewhere prominently on your page and see what happens – this is called “public beta”. If that is too crazy for you then you can password-protect your site and only share it with selected users – that is a “private beta”.

Very important: Get the idea out of your head that your product needs to be perfect before you can launch it! There are many minimalistic and half-backed products out there that are pretty successful. Early release beats perfectionism and the minimum viable product beats the over-featured product. Remember the early days of Twitter?

Cookie-Issues
Well this has nothing to do with food! In the web a cookie is just a piece of data that will be saved at the client computer. A bunch of very common features rely on cookies such as online-shopping or login-sessions etc.  It’s important for you to know that features that rely on cookies can be very painful to test because the features can behave differently depending on the client´s configuration of browsers etc.

“See you at 2 am!”
Well, in theory you can release a new version of your web product at any time you want. But maybe you don´t want to risk downtime during the peak periods of the website. So for bigger releases and maintenance operations, the early morning might be the only time-frame of the day with low traffic …and you and your team are working hard while everybody else is sleeping! If your website has a huge amount of traffic you might even consider to launch at the weekends, because usually the traffic is lower during those times.

Browser Issues
Creating a useful user interface for websites is a hard job. In the offline world you “only” have to think about which operating system and screen resolutions your target customers have. In the web you also have to worry about different browser versions, browser security & privacy settings, pop-up blockers etc. It is almost impossible to create a complex website that will work with all browsers.

My recommendation: Focus on the most popular browsers and be minimalistic with the product features. The best way to figure out which browser your web product needs to support is to take a look in your web analytics. The diversity of browsers can vary significantly depending on the target group or target-country of your website. At minimum, your site should support Firefox, Internet Explorer (even the old IE 6 is still a common browser) and Chrome.

Web Analytics
You will have lots of information about the users of your product – for free! Google Analytics is the most common free web analytics tool that will provide interesting information about your users. For example: number of visits, pageviews, average time on page, country, browser version, screen resolution, bounce rate, top landing pages and much more. Get familiar with these analytics tools and identify the strong and weak points of your product!

Website Speed
Even in the age of high-speed internet connections you need to have a fast website! Not only do users like fast websites, search engines love them as well! Listen to what Matt Cutts from Google says about this:

[Youtube=http://www.youtube.com/watch?v=muSIzHurn4U]

I hope this crash course will be helpful for you to kick-start your web product manager career!

—

Thomas Fuchs-Martin is web product manager & SEO at the Spanish internet start-up nuroa.es – More articles about web product management can be found at his blog: www.webproductblog.com

What Origami can teach us about Product Requirements

Tom Grant has started an interesting series of posts entitled Against a Grand Theory of Product Management. The articles are interesting reading, but make sure you have your thinking cap on when you start, because Tom is discussing an important but rather abstract topic.

He pulls in references ranging from Middle Range Theory (something I’d never heard of before) to Darwin’s theories (something I think we’ve all heard of but probably don’t adequately understand) to help convey his points. I had to read the posts a couple of times each to better grasp the specifics of his arguments.

In Part 2 of his series, Tom asks:

If someone can figure out why even the most meticulously written and reviewed requirements don’t stop some tech companies from making products that their users don’t like or can’t understand, that’s a big contribution to our little field of study. Best to have more middle-range theory before even thinking about the GToE [Grand Theory of Everything].

This is a great question. But before I answer it, I want you to watch the following video. It is from a TED Conference talk given in February 2008 by Robert Lang. Not only is this a fascinating video, but as you’re watching it, keep Tom’s question in mind. Don’t read on though until you watch the video. 🙂

[BTW, if you are impatient and read ahead, the important stuff starts at about 2:30 in the video.]

Lang talks about the evolution of origami, that took it from a traditional Japanese art form that most of us associate with creating things like this:

and turned it into an art (and science)  form that allows people to create things like this:

And what caused that evolution? In Lang’s words, the answer is “mathematics”, or more specifically, the creation and utilization of a set of rules that provide a language for defining what can and can’t be done in origami.

The rules define the crease patterns — the lines along which folds are made — in the paper. And there are 4 rules:

• 2-colorability — any valid crease pattern can always be coloured with only 2 colours and will not have the same colour in two adjacent areas.
• modulus (M-V) = +2 or -2 — at any interior vertex, the number of mountain folds and the number of valley folds will always differ by 2
• For any vertex, the sum of alternate angles around that vertex will always be 180 degrees. e.g. a1+a3+a5 … = 180 degrees  & a2+a4+a6… = 180 degrees.
• No self-intersection at overlaps – a sheet when folded cannot penetrate itself

[Note: if you don’t understand these rules, watch the video. 🙂 ]

Now these 4 rules define the properties of valid crease patterns, but there’s still something missing. How can those rules be applied to create sophisticated origami? In short, what goes in the box? (see 4:40 of the video)

Lang discusses that as well, and provides this diagram:

In short, the physical subject is reduced to a tree figure defining the key components (“flaps” in Lang’s terminology) of the subject. In this case, those are the legs, antennae, horns etc. of the beetle. That’s fairly easy.

Then some process must be used to take that tree-figure and create a base form for the final origami. He calls that the hard step.

And finally the base form can be refined to create the finished model. That’s fairly straight forward.

The “hard step” is accomplished using the rules defined above and the language for applying those rules. Given those rules are mathematical in nature, they can be written precisely and unambiguously and then executed to create the final model.

What does this have to do with product requirements and Tom’s question?

When looking at product requirements, there are analogies to Subject-Tree-Base-Model example given above.

• Product Managers investigate  real world problems, needs, scenarios etc. (Subject).
• They then take their learnings and create abstracted representations of them (requirements) using artifacts such as problem statements, personas, use cases and user stories (Tree)
• These artifacts are then used by engineering teams to create prototypes and mockups etc. to ensure that the requirements were understood and addressed in the product. (Base)
• The final product is built, tested, tweeked etc. with the appropriate “fit and finish” before being released. (Model).

Sounds pretty good so far right?

But herein lie the problems.

• There currently is no language for requirements like the one defined for origami, that can precisely and unambiguously convey what is needed and define that in a way that ensures it can be built.
• Requirements should be implementation neutral, but as we all know in technology, the ability to fulfill a requirement can often be limited by technology choices and decisions that were made well before the requirement existed.
• Other constraints such as time, resources, knowledge, legalities, finances etc. all factor into how well a requirement can be met, or perhaps if it can be met or not.
• In many cases requirements contain unknowns or ambiguities that are filled in by assumptions during the development process. This is a reality of developing products in a business environment.  In the origami situation, this is would never happen. A model (like the stag beetle) can only be built when the full crease pattern is defined.
• There is no concept of people “liking” or “understanding” the origami in Robert Lang’s rules. i.e. Tom Grant asks about why companies build product their customers don’t like or understand.

This last point is key and deserves a little more discussion. What people like and understand is complex and is not static. In general, what people like is based on overall experience and emotion. It is not something that (currently) can be defined in a set of requirements.

i.e. users of this product must feel giddy with excitement the first time they use this software

So, can origami teach us something about product requirements?

Absolutely. The origami path from Subject->Tree->Base->Model forms series of transformations that is akin to the requirements gathering, communication and development process used when creating products.

Once a set of clear foundational rules for origami were defined and understood, not only did they open up new possibilities for forms never thought possible, but those rules formed the grammar for a language that makes precise and unambiguous communication also possible.

There is almost certainly a set of rules and language for precise definition and communication of requirements, but it has not yet been clearly formalized. That is likely a necessary stepping stone in the maturity cycle of product development.

But even with that requirements language, changing market landscapes, customer preferences and needs, technological, resource and time constraints will all work together to make product success a “grey box”, where those with great vision, insight and execution are likely to succeed but never guaranteed that success.

Saeed

Support the Cranky PM at BoS 2009

While there are many places I’d love to be in mid-November, there’s definitely one place I really want to be (but can’t)  on Tuesday November 10, 2009.

And before I say anything else, let me tell you this is not a paid promo piece from the PR firm that promotes the Cranky PM. 🙂

Where would I like to be on Nov. 10? I’d like to be in San Francisco where the Cranky PM will appear live (from 2:30-3:00)  and speak at the Business of Software conference.  Last year, Steve Johnson was the big hit at the conference. This year, let’s help the Cranky PM!

As readers of our respective blogs may have noticed, We’ve had an ongoing, healthy online conversation(!) over the last couple of years. Here are a few from this blog:

• In Search Of: CrankyPM.com
• What’s the deal with Personas?
• What’s in a name? A PM by any other name…
• Saeed vs. Cranky PM: Fight!

And here are a couple from hers:

• On Engineering Meetings: Redux
• Three things the CPM doesn’t want to hear

Now, I’m sure there will be people who go to the CrankyPM’s session simply for voyeuristic reasons. What does she look like? Is she a she at all? Do her legs look like those in the picture? Is she as funny in person as she is on her blog? etc. etc.

I think people should go there to support her. I’m pretty sure that being a popular anonymous blogger has it’s benefits. But being a frequent speaker at conferences is NOT one of them.

So here’s a tip of the hat to the Cranky PM, and whether she decides to reveal her identity or not, try to support her by attending her talk.

And for those of us who can’t be there, please live blog or tweet it if at all possible! 🙂

Saeed

Product Management Metrics (part 2)

In Part 1, I defined the mandate of Product Management as:

Product Management’s mandate is to optimize the business at a product, product line or product portfolio level over the product lifecycle.

I’ve emphasized 3 words: optimize, business and lifecycle.

Optimization is the process of changing a system to make it work efficiently within a set of given constraints.

Fundamentally, this is what Product Management is all about: how to invest limited resources to deliver competitive products to market, that are in line with market demands and expectations and then working with other teams to better enable them to reach their targets that make up overall business goals. 🙂

Product Management must always keep business goals in mind and work to achieve or help achieve those goals within the context of the products or product lines.  Business goals are typically related to revenue, expense, customer acquisition, market share, geographic expansion or organizational improvement. This is a sample list of goals and doesn’t imply that Product Management must focus on these areas.

It’s important to keep in mind that business goals differ across the product lifecycle.  A product lifecycle can be defined as having the following stages:

• Development
• Introduction/Launch
• Growth
• Maturity
• Decline
• End of Life

There may be variations on these stages, but this represents the major phases that a product will pass through. And the goals and objectives for the product will vary at each of these stages. For example, the Development phase usually is pre-revenue. In this phase, Product Management is focused on understanding market needs and working with various parties (internal and external) to create a product or solution that addresses those needs.

With Launch, the goals for the product can include initial customer acquisition, validation of the product in the market, educating influencers, generating awareness etc. Revenue obviously becomes a major factor after Launch, as do goals such as customer retention and ongoing competitive differentiation. The other phases — Growth, Maturity, Decline and End of Life (EOL) — all bring their own challenges, constraints  and objectives.

Given the changing objectives over the product lifecycle, the goals of Product Management will change, activities to achieve those goals will change and the metrics that are used to measure them will change.

In part 3, I’ll get more specific, and lay out a model that people can apply to their products or product lines. It is important to note that there is no “one size fits all” solution here. Only at the highest level of business reporting– customer acquisition, revenue, customer retention etc. — can there be a single set of metrics for most products.

Because of the breadth of potential technology products — e.g. SaaS vs. Licensed software, a consumer product vs. a B2B product, infrastructure vs applications, a retail product vs. an OEM product  etc. — specific metrics across the lifecycle will vary.

Department vs. Role

I do want to make take a few moments to address a question related to role metrics vs. department metrics. That is, the metrics used for measuring a Product Manager, vs. the metrics used for measuring Product Management as a whole.

In small  companies, there may only be a single Product Manager for a given product or product line.  I’ve been in that situation myself a couple of times. In those cases, metrics for the Product Manager are pretty much the same as that for the Department.

But in larger companies, where there truly is a Product Management team, most likely with differentiated roles for PMs (e.g. Technical Product Manager (TPM) , Sr. Product Manager, Director Product Management etc.) the metrics that would be used to measure individuals likely would be different that those for the entire team.

For example, a TPM would likely spend much of their time working with Engineering during a development cycle or researching technical issues for upcoming releases, whereas a Director would be more focused on overall product strategy, business alignment, strategic partnerships etc.

The Product Management team may be measured on product revenue, delivering a new release successfully etc., but individuals in that team would have other role specific metrics tied to their individual activities and responsibilities as well.

As mentioned earlier,  in part3, I’ll get more specific and present a model that could be applied or adapted by Product Management teams.

Saeed

Canada’s Innovation Gap (part 1)

While this post is targeted at the innovation, funding and technology issues in Canada, it may apply to other geographies as well, particularly if you don’t live/work in technology hot spot such as Silicon Valley or Boston or Banglalore etc. This is a topic that is very dear to me, given that I currently live and work in Canada, but spent 6 years earlier this decade living and working in the San Francisco Bay Area.

A couple of weeks ago, there was an great article in The Globe and Mail newspaper (one of Canada’s leading daily papers) entitled Canada’s innovation gap. The article, by Konrad Yakabuski, outlined what I think is both an accurate and troubling picture of the state of R&D and innovation in Canada. Here are some highlights from the article.

• Innovation in Canada is in deep trouble. Productivity is stagnating; the manufacturing sector in imploding, and the government policy makers seem asleep at the wheel.
• Once the flagship of Canadian high tech, Nortel is being dismantled and it’s best assets are being sold to foreign companies.
• While Blackberry maker Research in Motion is a true global leader, and often cited as an example of what is possible in Canada, there are few if any other Canadian companies that can be held in the same light.
• Canada’s economy is heavily resource based, and those companies spend very little of their revenues on R&D, even though they made enormous profits before the recession due to high commodity prices.
• While Canada was moderately successful at moving from a provider of raw resources to foreign countries to a more modern economy, the last 10 years have reversed that process.
• Historically, the  small group of elites that got rich on these resources controlled the political levers to ensure nothing changed. [Note: I personally think this still applies although not as much as it once was]
• Innovation is the only sure way for Canada to be more productive.

I could go on. It’s a great article, and it should be a wake up call to every politician and business leader with any sense of commitment to the future and well-being of this country.

Change is a process

Change is needed on a lot of fronts. While many politicians are quick to highlight that the Canadian economy has faired better than other industrialized economies in the current economic crisis, it doesn’t change the fact that there has been a huge disruption in the Canadian economy, widespread layoffs, plant closures and bankruptcies.

Keep in mind that billions were spent to help manufacturing companies, particularly automakers with vociferous unions, but little if any was spent or allocated to help technology companies or create environments to make investment in high-tech much easier. A quote from the article:

“Canada is not being productive because it’s not being innovative,” said Robert Brown, chief executive officer of Montreal-based CAE Inc., the world leader in aircraft flight simulators and training. “A lot of innovation occurs at the interface with the customer. But when you look at the make-up of Canada’s economy, with so much dependence on resources, there is less contact between [our biggest] companies and end users.”

I think this is a polite way of saying that there are a lot of companies that are more than happy to cut down trees or dig minerals  or pump oil out of the ground and then ship it off to some other country to be processed and have value added to it.

Aside from being innovative, Canada needs to look to add significant value to whatever industries it has. We have great R&D minds in this country, but there are problems in productizing the research and funding and scaling businesses.

My personal experience

I moved to California back in 2000 to seek better opportunity – i.e. professional and financial gain — than I could find here in Canada. One of my best friends from high school — a brilliant guy who did his undergrad at Harvard and his Ph.D at Princeton, is now a research professor at another Ivy League school, even though he really wanted to come back and live and work in Canada. He told me back in the early 90s that the opportunities just weren’t here for him. He’s a great example of the brain drain this country faces on a regular basis.

I moved back to Canada a few years ago for personal reasons and I have to say it wasn’t easy coming back. Aside from the nicer weather in California, I knew that my career opportunities would be more limited than they were there.

And trust me, there is a huge difference in the technology industry here in Toronto and that of Boston or San Francisco. Everything from the amount and quality of investment funding, to the networks of people with connections into technology giants to the breadth of skill sets of individuals, and even to the aspirations of company founders are very different.

We’ve got brilliant people

I’m not slagging anyone here. There are very bright, dedicated and passionate people here. I’m proud to know a number of them. But when it comes to goals, too often a Canadian VC or company founder sees a $50 million exit as a big win, whereas in the US, that’s on the low end of their success scale.

And that exit often means jobs moving to the US or offshore. In many cases the key people in the acquired company (the bright, dedicated and passionate ones) move down to the US to work “at corporate”, and the brain drain continues.

I don’t want to paint a completely bleak picture of the situation here. As I said earlier, there are very bright, talented and passionate people here. In fact, after I moved down to Silicon Valley in 2000, one thing I realized was that the people down there are not smarter than the people here.

But the level of investment financing, the personal networks of skilled people, the institutions like Stanford and Berkeley all provide a critical mass of infrastructure that enable risk taking and innovation on a scale we don’t really have in Canada. The infrastructure and culture there pull bright people from other parts of the country and other parts of the world.

The issue is not the people here in Canada, it never has been. It’s all the other business levers that innovators need to “nail and scale” their businesses to be world leaders. I personally think the co-founders of RIM (Mike Lazaridis and Jim Balsillie) should be viewed as national heroes, on the same scale as Wayne Gretzky or Gordie Howe (famous hockey players for those of you who didn’t grow up on hockey!).

I’m sure Mike and Jim had numerous incredibly lucrative offers to sell their company over the years. But they didn’t. They held on, grew the company, fought off lawsuits, challenged rivals and continued to innovate and create a global leader based in Waterloo Ontario. And just recently RIM was named the fastest growing company in the world by Fortune magazine.

So what can be done to close the innovation gap? Konrad offers some solutions in his article. I’ll get more into that in part 2.  But in the mean time, I’d like to hear what you think, particularly if you are here in Canada, or are Canadian and are living/working outside of Canada.

Saeed

Related Article:

Canada’s Innovation Gap (part 2)

Guest Post: There’s no such thing as MEDIUM

NOTE: The following is a guest post by Tzvika Barenholz, a Product Manager living and working in Israel. If you feel inspired to write a guest post of your own, click here to find out how to submit it to us.

We all know the situation: you’ve collected a bunch of product requirements, put them into a nice excel sheet or clever table-like GUI front-end; you’re all psyched about making the big decisions, prioritizing and leading the product to the proverbial “next level”. You sit in front of the screen, crack your fingers, stretch a bit and place your hands in the typing position.

“First item, feature xyz” – yes, you say it out loud, you’re psyched remember? – “First column, Importance” (or priority, or appeal, or whatever is your favorite alias for customer value)

OK – now what *was* the priority of feature xyz?

Let’s see. A couple of big customers have asked about it in a recent expo, so probably high, right? Then again, it’s one of those things that make the product more complicated, so call it low. Having said that, it would really improve average sale price, which is aligned with the five year plan, so high it must be. But what about breadth? It really would only appeal to a fraction of our customers. Back to low again.

And on, and on.

Exasperated, you note that after 20 minutes you’re still on item #1 out of 37. It’s looking more and more like a long night of pizza and coke with the developers. The next thing you know, there’s a little voice inside your head that whispers: make it a medium!

Of course! How foolish you’ve been to overlook this possibility before. A medium is right in the middle between high and low. It’s the perfect answer for what seems to be neither here nor there, or both here and there. Your right index finger then makes it merry way to the m key.

But STOP – you’re just a moment away from falling into a trap as old as the hills. Why? Because there is absolutely positively no such thing as a medium, except maybe as a shirt size.

“Medium” is a shirt size, not a useful priority rating

Prioritizing something as medium is just a way chickening out of making a decision. If you don’t have enough information to make the call, go get the information, then make the call. If you’re piling up different qualities like “broad appeal”, “helps sales”, “improves margins” and “technologically strategic”, then by all means, add 4 columns, fill them out with highs and lows (or yes or no, for the more advanced practitioners who know how to make an even cleaner cut), and then rebuild the priority column as an index composed of them all.

But whatever you do, don’t just cop out. Don’t just type medium and move on to the next item, or you will end up building the wrong things for the wrong reasons.

Upcoming ProductCamps

ProductCamp New York was last weekend and it appears to have been quite successful. Alan attended and wrote up this post about it.

If you missed the New York session and want another chance to attend one, there are 4 5 more in the works in the coming months, starting with ProductCamp Austin in only a few weeks.

ProductCamp Austin
Date: Saturday August 15, 2009
Location: The University of Texas at Austin, McCombs School of Business, Austin
More details: click here.

Followed by one in September.

ProductCamp RTP2
Date: Saturday September 26, 2009
Location: Cambria Suites, Raleigh-Durham Airport
More details. click here.

And 2 ProductCamps in October.

ProductCamp Toronto 2009
Date: Sunday October 4, 2009
Location: Ted Rogers School of Business @ Ryerson University
More details: click here.

ProductCamp Seattle
Date: Saturday October 10, 2009
Location: Amdocs, 2211 Elliott Ave, Seattle WA
More details: click here.

And to round the year off, Boston is holding their camp in November.

ProductCamp Boston
Date: November 7, 2009
Location: Microsoft New England R&D Center, Boston MA
More details: click here.

For information on these events as well as other events relevant to the Product Management, Product Marketing and Product Development communities, check out our Events page. And if you know of an event we should list, let us know in the comments of that page.

Saeed

Guest Post: Triangle Offense and Scrum Mania

NOTE: The following is a guest post by anonymous blogger GeekMBA360, author of the blog by the same name.  If you feel inspired to write a guest post of your own, click here to find out how to submit it to us.

– – – – – – – – – – – – –

Phil Jackson has won more NBA championships than any other coach in history. He won six championships with the Chicago Bulls, and then won another four championships with the Los Angeles Lakers.

If you’re a basketball fan like myself, you probably know that Phil Jackson utilizes a unique offensive system called the Triangle Offense.

The Triangle Offense has been around for a long time. According to Wikipedia:

“the triangle offense’s most important feature is the sideline triangle created between the center, who stands at the low post; the forward, at the wing, and the guard at the corner. The team’s other guard stands at the top of the key and the weak-side forward is on the weak-side high post — together forming the “two-man game”.

The goal of the offense is to fill those five spots, which creates good spacing between players and allows each one to pass to four teammates. Every pass and cut has a purpose and everything is dictated by the defense.”

I’d like to make a few observations about Phil Jackson’s success and his use of the Triangle Offense.

First, Triangle Offense is neither sufficient nor necessary for winning a championship. It’s true that both the Chicago Bulls and Los Angeles Lakers had great successes with the system. However, there are also many other teams who had been very successful by employing other offensive systems.

For example, the San Antonio Spurs has won four championships between 1999 and 2007 (the most in the NBA during that period) by having a totally different system. Other championship teams such as the Detroit Pistons and Houston Rocket also had very different offensive systems.

A good team implements whatever system fits it the best. It doesn’t try to impose a system on a group of players.

Second, triangle offense requires the right combination of players. Because it is such a fluid system, it requires the players to be very flexible. For example, the systems prefers a big-man center who can pass the ball well, and a small forward who can defend and shoot the 3-pointer. It’s a complex system. The players must have the patience to learn and practice in order to play effectively in the system.

It’s not a system that could be retrofitted to any team. Some players are simply not good fit for the system.

Third, Triangle Offense requires an excellent personnel manager and a solid X’s & O’s guy. According to this ESPN article:

“Being a great NBA coach is about managing egos, earning your players’ respect, developing team chemistry, making (in-game and off-day) adjustments, and emphasizing the right things. And no one’s ever done all that better than Jackson.”

Phil Jackson has Tex Winter as his assistant coach. Tex Winter literally wrote the textbook on triangle offense, and is an expert in teaching the X’s and O’s of Triangle Offense. Clearly having the right supporting cast is incredibly important.

The relationship to Product Management

Now, let’s move to our professional world of product management and software development.

In the past few years, I think our industry has had a “Scrum mania” — there are armies of consultants and trainers who tout the merits of the Scrum methodology. Company executives send people to get “Scrum Master” training and assume that their products would be shipped on-time.

An example from real life

I worked for a start-up company that provided a hosted data mining product. It had about 30 clients. Each client had a separate instance of the application.

Because of the amount of customization for each client and complexity of the software, it would take a couple of weeks to deploy a new version of the software since the new software had to be tested for each client. The deployment process was a little bit different for each client due to customized settings and configurations.

The development team had been doing a good job. But, one day, the big boss attended a seminar on Scrum. He wanted the company to adopt Scrum methodology. He sent two Program Managers to get certified.

He even brought in a trainer to give all of the developers a one-day Scrum training session. His rationale is that instead of shipping a new release every three months, we’ll get something done and ship product every month.

It was a disaster.

Most developers on the team used to work for large packaged software companies such as Microsoft, Oracle, etc. They were excellent developers who were used to the waterfall development model. And most of them had been working at this start-up for a long time.

They rebelled against the Scrum process. Instead of daily Scrum updates, they’d much prefered spending the time on design and coding. They also hated to update their tasks using the Scrum software.

Because of the complexity of the software, each developer got very little done during each 3-week scrum cycle. And then they have to attend another several hours of scrum planning. It became very inefficient.

The morale was low. Scrum Masters and developers spent hours debating the right way to do Scrum during each Scrum planning session.

You could argue that this company implemented Scrum incorrectly. There is nothing wrong with Scrum itself.

However, I think this is an example of a company that probably should not have implemented Scrum at first place. Just like the Triangle Offense, Scrum is a methodology, a system.

Scrum is neither sufficient nor necessary for running successful software projects.

Scrum requires the right combination of personnel: Developers must buy into the new systems, and be willing to adapt. In this example, the company had a group of very experienced, senior developers who were used to a waterfall development model that had worked well in the past. It was very hard to get their buy-ins, especially given the nature of the products they were building.

Running successful Scrum requires a excellent personnel manager and a solid X’s & O’s guy. In this particular company, the Scrum Masters were well trained. However, the development manager and senior management team didn’t fully understand the cultural and organizational challenges of implementing a new system. And this was what led to the downfall.

Are you thinking about putting a new system in place? Think and plan carefully. You want to put in the best system for your organization. Simply adopting systems used by other organizations won’t work.

—

GeekMBA360 is a product management executive with over a decade of experience in e-commerce, online advertising and enterprise software. His blog,  GeekMBA360.com, offers career insights at the intersection of business and technology. He also publishes the popular Great Depression 2.0 Survival Guide for High Tech Professionals.

The value of simplicity

We have 3 different types of food blenders in our house. They are pictured below. I’ve tried to show them roughly to scale with one another.

The first is a “traditional” blender with a base, a large 56 oz. (1.75 L) pitcher-style container and several speed settings for the blades.

The second is an immersion blender with a number of attachments for mixing, blending, chopping etc.

The third is known as the Magic Bullet blender. It has a small 16 oz.  (.45 L)  container for the contents being blended and a simple on/off mechanism for the blades.

While they all have benefits and are clearly different, guess which one gets the most use in our household? Given the title of this post, it should be pretty obvious.

Yes, it’s blender #3, the Magic Bullet. And why?

Simplicity in all aspects of usage. Most blending jobs are very simple quick tasks. e.g. making a smoothie, or blending some sauce or something similar. The usage scenario goes something like this:

1. Place the contents to be blended into the blending  container
2. Blend for 10-15 seconds (maybe 20 seconds in extreme cases)
3. Pour the contents out of the container

There’s not much more than that. In *most* cases, the amounts are small (< 16 oz) so I don’t need the large blender which is both heavy and a bit of pain to clean. Also the immersion blender is pretty good for a lot of tasks, but I find it inefficient unless I truly have to immerse it into a pot or other container for “in place” blending.

In short, for the majority of my blending tasks, the Magic Bullet addresses the needs well. There is a lesson here for software and technology PMs, and I think you know what that is:

A simple solution that addresses a use case well is likely to be used often by your target audience.

Of course, most technology products do a lot more than a blender, but that doesn’t mean they have to be complex to use.

Saeed