If you’ve even come close to a business book in the last 5 years or so, you have probably discovered that “innovation” is what every IT organization is desperately trying to capture, grow, encourage, enhance, etc. Although this sounds like a great idea, and IT product management is one area that would directly benefit from this, it turns out that it’s actually quite hard to do consistently over time. What gives?

One of the key skills that an IT organization needs in order to be innovative and to develop better IT products, is the ability to brainstorm as a team well. We all THINK that we know what it means to brainstorm; however, it turns out that more often than not we are wrong. Too often we think of brainstorming as being a solitary task where we go off an think about a problem until an apple drops on our head and the answer emerges. Matt Bowen who is the CEO of Aloft Group spends a lot of time teaching his marketing firm’s employees how to brainstorm as a group — a much more powerful form of brainstorming. Here are his suggestions for how you can learn to use this powerful tool:

• Creativity Starts With The Hiring Process: When you are inviting people to join your team, you need to make sure that they will be able to contribute to the group’s ability to innovate. This means that you need to understand how they think. A great way to do this is to ask them to tell you stories about jobs that they’ve had. If their storys revolve around creating new solutions than you know that you have a creative type. If instead, they focus on incremental improvements in the way that things are done, then you’re probably talking with an operations person.

• How To Prepare To Brainstorm In A Group: The best way to learn to do this is to jump in and just do it. You will need to have a designated facilitator to lead the process. The first thing that the facilitator needs to help the group do is to very clearly lay out a single sentence that clearly describes what the goal of the brainstorming session is. Distribute this sentence a day or two before the meeting to everyone who will be attending so that they can start to think about it. Also, the facilitator needs to spend some time establishing criteria for how he/she thinks the resulting ideas need to be rated. What’s are the most important characteristics of a solution and how should you rank them?
• Group Brainstorming Rules: Never have the meeting last more than an hour. Limit the size of the meeting to no more than 5-7 people (less if the facilitator is new to this). Try to make sure that the participants come from different departments because this will help to ensure that you get multiple perspectives. Normal brainstorming rules apply: no critiquing, no editing, no such thing as a bad idea, and always try to build on other people’s ideas.

The real key to successful brainstorming lies in what you do AFTER the meeting. The facilitator needs to assemble a group of people to rate the ideas generated by the brainstorming based on the criteria that was established before the meeting. This group can be different from the group that created the ideas.

Finally, don’t you let the resulting ideas die! In order for brainstorming to catch on in any IT department the staff need to see changes occurring that they can clearly relate back to brainstorming sessions. Do this and you’ll have an innovative IT department that will be the envy of the rest of the firm.

Tags: innovation, innovation, program managers, IT products

No related posts.

Let’s look at the respect pyramid that, although unofficial, exists in nearly every IT organization. If we start at the top, then we find the Subject Matter Experts (SMEs) who are the people who really know what’s going on both in the company and with the technology. These are the people who make sure that the team is really solving the right problem: “That won’t work because that’s not the way that we take orders for that product…” Just under them you’ll find the legacy crew — those folks who have been working on a system or a technology longer than anyone else and are the ones that everyone goes to in order to solve technology problems. Beneath them you will find the code rockets. These are the folks who have an amazing ability to turn out code or other productive work seemingly overnight. When a schedule gets tight, they are the ones to turn to.

Once you get this far down on the IT respect pyramid, things get a bit boring. That is until you get to the bottom. I’ve got good news for the IT Product Management world, we’re not at the bottom. I truly believe that the bottom of the IT respect pyramid is reserved for the good souls who work on the Quality Assurance (QA) team. Just above them (doing better, but not by much) are the Program Managers. The bad news is the Product Managers sit just above Program Managers which is way to close to the bottom of the pyramid if you ask me.

This, of course, begs the question: why? How did IT Product Mangers come to live so close to the bottom of the respect pyramid? If you take a look at who is up at the top, you’ll notice something very interesting: the most respected people in an IT organization are givers, not takers. Sure there are exceptions to every rule, but this is most often the case. Way down at the bottom of the respect pyramid you find the folks who are viewed (rightly or wrongly) as basically being takers, not givers.

This sad realization generates the question, so what can be done to improve the lot of IT Product Mangers? Clearly Product Managers need to find a way to be seen as givers. So what do we have to give? The three quick answers that come to mind are direction, status, and understanding. Direction has to do with making sure that the IT team knows what they are working on and what problem it is designed to solve. Status means making sure that every member of the team fully understands at all times how the product is coming along and what the outside world thinks about the product team. Please note that an occasional “Status” email does not even come close to accomplishing this goal. Understanding is the most important and the most difficult to do. The IT team lives an insulated life and often times does not understand why certain decisions are made or why the team or the product is viewed as it is. It is the Product Manger’s responsibility to monitor all of these things and relay them back to the team in terms that they can understand.

Can IT Product Managers climb up the IT respect pyramid? Yes, but it won’t be easy. If you are willing to give it time and constant attention, then you will eventually find yourself on top of the pyramid of respect and isn’t that where we all want to be?

No related posts.

By Dr. Jim Anderson

So what makes one IT product manger any better than another? I’ve spent a lot of time both working as a product manager and working with other product mangers and I think that I’ve got this figured out. I think that we can all agree what a good product manger looks like: they have successful products that customers want and internally everyone wants to work on their product because it is recognized as a “good place to be” from a career point-of-view. On the other hand, a bad product manage is also recognizable because their products are struggling, nobody really understands what they do or why they are any better than anyone else’s products and internally nobody is excited about working on anything that touches this product.

So how do good product managers get that way? The key is that really good product managers know their product and the environment in which it operates inside and out. This is the one thing above all others that sets them apart. All too often, program managers get placed into product manager positions (I mean after all, aren’t they really the same thing?) and don’t make the transition that is required to fully become a product manager.

Program managers (and bad product managers) tend to focus on just the day-to-day parts of creating and launching a product. Good product managers do the same; however, this doesn’t take up all of their time. Instead, good product managers spend a considerable amount of time trying to prepare customers for the new product / features and making sure that end user feedback gets back to the product developers even as the product is being created.

You would think that at least bad product managers would have projects that run more smoothly because of the extra time that they invest in program management activities. However, this is generally not the case. I believe that the extra level of motivation that the rest of the team brings to a good product manager’s product development program allows him/her to spend less time managing the process and more time making sure that the product will be well received.

No related posts.