Thanks everyone for the great conversation in the most recent #prodmgmttalk chat session!  This week, Roger Cauvin inspired us to think about product managers as innovators – or enablers of innovation.  Each week, I find myself thinking about at least one of the #prodmgmttalk questions long after the hour is over.  This week’s thought – organizations prevent product managers from innovating.

Innovation and Product Management

What a great topic.  I’ve never met a product manager with a goal of solving valuable problems who didn’t aspire to creating innovative products.  Maybe you’re out there – say howdy if you are.  Roger’s topics, Cindy and Adrienne’s moderation, and the great community that is forming around the weekly #prodmgmttalk chats created a great hour of thought provoking discussion (brainmates’ summary;  full transcript).

Before diving into how organizations prevent product managers from innovating, I want to frame the discussion around a particular definition of innovation.

While there were several different definitions of innovation proposed during the session, I’m partial to one that I articulated during an  Accept 360 webinar last year on Innovation and Transparency (video; slides).

From the presentation on Innovation and Transparency:

Innovation = Valuable Invention

Putting it visually:

For a product manager – the focus is on discovering the value.

Roger has a great perspective on this product-management-centric view of innovation:

True innovation comes from understanding the problem in solution-neutral terms. So Product Management first attempts to understand the problem thoroughly & communicate it to designers. By framing the problem clearly, Product Management enables designers to unleash their creativity & skills. Peter Drucker speaks of “purposeful”, systematic innovation. Product Management is a big part of systematising innovation.

Roger Cauvin via Brainmates

However, innovation is not just about solving valuable problems (that’s just good product management) – and does not have to start “market first.”  Innovation can also come from discovering applications of novel technology – invention.

A researcher discovers an adhesive that is not strong enough for tape – but can be used over and over – and we have sticky-notes.  Another scientist accidentally leaves a chemical mixture in a beaker overnight and tada! – bullet-proof glass.  This is the view of innovation that seems most pervasive in the collective consciousness – someone invents some awesome thing and then finds a good use for it.

You can have a sequence that works either way – discovering market applications for a new technology, or inventing solutions that address market problems.  Innovation is what you get when you do both.

Another fun example to think about – the light bulb.  Did Mr. Edison start with a market problem (candles are not a good solution to “see stuff at night”) and end up with a light bulb?  Or did he start with an invention (distributable electricity as a service), and try and “invent” a market use?  I never met the guy :), but my hunch is the latter.

The problem is that product managers aren’t inventors looking for market opportunities.  We don’t create hammers and run around looking for nails (or things to hang up).  We engage our market, discover that bare walls are a problem (and people are willing to pay to solve it); then we work with our teams to find ways to hang pictures.

Common Organizational Approach to Innovation

I’ve worked both for and with several companies – large and small – that take this inside-out approach to developing innovative products.  Google is famously known for their “twenty percent time” – which gave us GMail and Google News.  Microsoft now has a policy where employees get to keep the intellectual property (and a share of the revenue) from their side projects.  Inventor-inspired (or developer-driven) projects are more likely to create something novel, and less likely to create something valuable.

As a related anecdotal data point – what percentage of start-ups actually succeed in the market?  I bet there are hundreds or thousands of failed start-ups for every winner.  Most small businesses close their doors in less than five years.  However, that stat includes all businesses, as this great discussion on Quora highlights.  Still – even those statistics reflect business failures, not product failures.  Most businesses have a failed product or two (or two hundred) in their past.  Even Facebook’s first “product” failed, before Mr. Zuckerberg created The Facebook.

Back to organizations.

In the crazy stream of conversation, the following caught my eye:

Whether Product Managers are innovators or innovation enablers depends on the organisation & size of your group. Additionally some orgs have a Product Planning role which precedes Product Managers, moving them to an innovation enabler role.

Rich Velazquez via Brainmates

Yup. Seen that a lot. Don’t care for it.  I think it is dysfunctional to decide what products to create / problems to solve without product management.

That neuters your product managers – making them order takers – and they lose the ability to birth innovative products, left to only participate as midwives in the process.

Bill Bliss wrote an article with great visuals describing the product planning process, (check it out) where he shows how the flow from “vision and mission” breaks down before it gets to products.  He highlights that responsibility shifts from one group to another, and that the process typically breaks during that translation of goals into products (he says ‘projects’).  He references a great article from the Silicon Valley Product Group on establishing a product council that assures product management participation (among other things) in that key “decide where to invest” step.

When product managers don’t participate in the planning process, we don’t have strategic relevance, and we aren’t innovators – we’re order takers.

Call to Action

If you’re in an order taker role with a product manager title, your goal should be to inject yourself into the decision making process.  The specific steps you need to take depend on your specific circumstances.  The skills you need are the ones you already have – story-telling, inspiration, leadership-without-authority, stakeholder management, executive communication.

OK.  So – go do it.

ps: If you weren’t here (at Tyner Blain) in 2006, go read these Top Ten Tips for Preventing Innovation.  Another tip would now be “prevent product managers from deciding where to innovate.”

In this week’s #ProdMgmtTalk, one of the livelier discussion topics was around gaining insights into your market – and what does that mean (to you)? Steven Haines was the speaker for this session who prompted us to think, and pushed us to rethink our views on market insights.  What a great example of collaboration among product managers!

Collaboration

In an email-interview with Craig Brown, creator of the Better Projects site, for an upcoming article, I admitted to Craig that I felt one of my mistakes was not taking advantage of enough of opportunities to collaborate.

#ProdMgmtTalk, a weekly Twitter-chat session on product management, co-hosted by Cindy Solomon and brainmates‘ Adrienne Tan, had its inaugural session this week. It was a great forum for collaboration and connecting with some obviously very sharp and seasoned product managers!

I’m thrilled to be the Catalyst of Discussion next week (definitely a more apt title than speaker).  Pretty intimidating to be in the slot between @Steven_Haines (transcript of session) and @Jim_Holland.  The rest of the lineup looks stellar too – I’m thrilled to have had the opportunity to work with, learn from, grab a beer with, or at least talk with most of these folks already; and hope to do the same with the rest!

One great thing about a Twitter-chat session like this is that when you’re passionate about the topic and want to join in the discussion, you just do – without having to bide your time or risk talking “over” someone else.  Everyone’s thoughts are shared and consumed – often simultaneously.  Occasionally, some contributions go by too fast – but it is great to be able to carry multiple-threads of conversation at the same time, without ever feeling frenetic.

One downside – thoughts are expressed in 140 character chunks.  For many things we do, and think, care, and talk about in product management; 140characters are inadequate.  And yes, Stewart, I know that 1,000 words probably aren’t ”required”.  There’s probably a happy medium.

Market Insights

Steven Haines, author of The Product Manager’s Desk Reference, got the discussion started with some great questions around “Best in Class Product Management.”  A great conversation thread (multi-thread, really) was started around what it means to have market insights.  In her writeup of the session, Adrienne pulled together a lot of great quotes around the theme.

Combining some of the ideas from the folks in the session:

• Market data = (data about) the industry, market trends, your competitors, your (existing and prospective) customers, your market segments, and your competitors’ products.
• Insight = understanding that is distilled from market data.

Unfortunately, the conversation only lasts for an hour.  Not enough for me.  I think there’s an important next topic for the group:

• OK, you have market insights.  What do you do with them?  And how?

Next Week

Make sure and join in the #ProdMgmtTalk conversation next week (follow the link for times and instructions).

And here’s a tip – there will be a link to this article, as “prep material” for the session.

If you want to seed the conversation with some long form (more than 140 character) thoughts and answers – add them to the comments here.  Folks will read them before the session starts.

Does product management slow down your company?

What Causes Your Business to Be Slow?

Paul Young put out the call for the third annual You Might Be A Product Manager… list.  If you are spending your holiday wondering if Jason Calacanis is right, and product management is actually preventing your company from being successful, you might be a product manager.

Facebook’s success — and mistakes — are based on its developer-driven culture, not because Zuckerberg is some evil mastermind.

The Zuckerberg Doctrine: Developers design products with significantly improved speed and functionality compared to product managers and designers, outweighing potential mistakes and drawbacks.

Jason Calacanis, Launch newsletter 002

Sound like link bait?  Maybe, but you’re probably a product manager :).  Jason’s put his money where his mouth is – he changed the way things are done at Mahalo (his human-curated search / answers company).

In under 30 days, we completely overhauled our product-development process, removing everything between the developer and iterating on the product.

We eliminated positions and process. We made it clear the developers were to make the decisions even if those decisions resulted in a developer being 50 percent slower because they were busy *thinking* about the product (as opposed to just transcribing features from the product manager wireframes).

Jason Calacanis, Launch newsletter 002

As you read through the details of the analysis in Mr. Calacanis’ newsletter, you’ll see that his position is not ultimately as generalized as the above quotes appear to be – Mr. Calacanis (who I’ve seen, and to whom I’ve listened for several years, but never met) is talking specifically about startups.  However, he uses AOL, Yahoo, MySpace and Google as his “bad” examples – not exactly startups.

I think this logical flaw may be leading Mr. Calacanis to demonize the wrong bad actors.

ProductCamp Austin 6

If you’re planning to attend ProductCamp Austin 6 – January 15th, 2011 (register here if you haven’t already), then consider attending a session that John Milburn, Roger Cauvin, and I are going to host – discussing this topic.  If you can’t attend, then jump into the conversation here.  John and Roger and I have been talking about this and exchanging some ideas since the newsletter came out – and we really know how much better ideas get when we open the conversation up to the community.  We’re looking forward to doing that at product camp, and I’m writing this to open it up now – so please, chime in!

Implicit Product Decisions

When I was still writing software and leading teams that were writing software, I would occasionally point out that all software is designed – even if someone sits down and just starts typing code.  There is, at the minimum, implicit design happening in the mind of the programmer.  It might not be “good” design, but there is always design.  There is always a method to the madness, just not always a considered method.  The same is true of product management.

• The creation of every feature and capability, in every product, is preceded by the notion that having this capability is a good idea.  That’s what product managers do – decide which capabilities a product should have.
• Eliminating product managers does not eliminate product management.

If “developer led” companies are still doing product management, how then, are they moving faster?  Mr. Calacanis addresses valid points – his “bad examples” do seem to move pretty slowly, and his “good examples” do seem to move faster.  So what’s really different?  John and Roger and I will be framing the discussion at ProductCamp around how to move faster, and not throw the baby out with the bathwater.

I might describe what Mahalo has apparently done as follows:

• Mahalo, with product managers involved in product decisions, was not moving as fast as Mr. Calacanis desired.  So they reorganized so that product managers were no longer involved in the process – in hopes of having a faster process.  Mr. Calacanis indicated that in a trade-off between “better” and “faster,” he would prefer “faster.”

Agility

The core of the agile development philosophy is – “fail fast. learn. improve.”

All of the other stuff in the implementations of agile comes back to this – consider the main ideas in the agile manifesto*

• People over process: empowerment to fail and learn and improve.
• Value working software: learning is experiential, and you can’t fail or improve without shipping.
• Collaboration: You have to understand someone else’s problem before you can solve it.  Too many products emerge from insular and isolated “exploration.”
• Encourage, don’t inhibit change:  If you punish failure you prevent learning. If you prevent that new knowledge from being applied, you make learning irrelevant.

*Agreed – those aren’t the words used in the manifesto.  Same ideas, though.

When you talk about business agility, while the mechanics might be different, the goals are the same.  Fail fast.  Learn.  Improve.

Mr. Calacanis, in my interpretation, is saying that this is exactly what he wants the Mahalo team to do.  I applaud that goal.

Does he have to “kill all the product managers” in order to infuse his company with (business) agility?

Is product management the antithesis of agility?  By definition, product management is still happening – just without product managers.  Maybe the product management process has room for improvement…

Market Driven

As a good product manager, you are market driven.  What does that mean to agility?

• Fail Fast.  Maybe you’re making decisions that delay launches until you know “the right product.”  That would hurt agility.
• Lean. Are you listening to your customers, and learning from them?  Great!
• Improve. Does what you’ve learned lead to trying something different, with a hypothesis that it will be better this time?

OK, so being market driven will help your company learn and improve.  That’s the up-side.  It may also enable (but not cause) some corporate dysfunction. If your organization punishes failure, or is afraid of mis-steps, and you’re market driven, you have already heard this conversation – don’t (schedule | design | release) until we get [feedback X] or [insight Y].

A tight coupling with your market is a powerful tool.  It can be used for good (learning) or evil (avoid failure).

Whew.  Good to know that being market driven is not the source of the problem.  An organization that is afraid of failure is the problem.

Mahalo’s experiment may work – Mr. Calacanis clearly intends to encourage the “fail fast” element.  So, when his developers are doing product management, they will have an opportunity to succeed by being market driven.

Bureaucracy

In fairness, Mr. Calacanis is really only prescribing the “no product managers” approach for startups.  Startups are not particularly bureaucratic.  Perhaps Mahalo was becoming bureaucratic.  It is easy to see the big companies mentioned in the newsletter as being rife with bureaucracy.  Even if you could fail fast, learn, and improve in a world of t-crossing and sign-offs, your definition of “fast” would not match your competitors.

Piloting your company would be like flying a Cessna twin-prop airplane in a world of super-sonic Gulfstream jets.

How are product managers introducing overhead into your product creation process?  What parts of product management are “not worth the delays?”

There are very real “slow things down” activities in the product creation process.

• Some activities can be removed.
• Some activities can be improved.
• Most activities can be done in parallel with the product creation process, eliminating delays.

What Have You Seen?

There are a lot of stories from the trenches out there – what are you seeing?  Have you tackled this already?  How did you make it better.

I hope that our session focuses on helping attendees, in a very real way, make their product creation process more effective, and make their businesses more agile.

Of course, we don’t have to wait until January 15th – we can start talking about it right now…

ProductCamp Austin is here again!  The Spring 2010 session is this Saturday, 27 March 2010 at the AT&T Conference Center on the UT campus in downtown Austin.  Make sure and say hi when you’re there!

ProductCamp

ProductCamp is an unconference for product managers and product marketing professionals.  This is the fourth time Austin has had one – we were fast followers of the wildly successful Silicon Valley PCamp in 2008, which Rich Mironov was instrumental in getting off the ground and growing.  Paul Young is the guy who brought together the people in Austin to get our events off the ground.  Paul graciously deflects the credit for getting things going, but he deserves it regardless.

Check out Paul’s great description of ProductCamp. Here’s the key paragraph, if you’re on the fence about attending:

The sessions and networking are the main reason that people keep coming back. Over three ProductCamps, we’ve achieved over 98% of participants answering “yes” to the questions “would you come back to ProductCamp” and “would you recommend ProductCamp to a peer?” This high customer satisfaction is why our local community loves to come out – in droves. Last time, we had over 500 sign up and over 300 participate. This time we are limited by our venue and won’t be able to hold more than 300 or so, so register today and reserve your space. It’s free of course.

Sign Up Now

Today (Thursday) is the last chance to sign up, to give folks a few minutes to finalize planning for space, make name tags, etc.

You can sign up at the official website for PCamp Austin.  The doors open at 8:30, things get started at 9:00, sessions are from 10-4 (with provided lunch at noon), then awards and a happy hour at 4:30.

View Larger Map

Sessions

41 Sessions have been proposed for this ProductCamp, so make sure and come, vote for your favorites, then enjoy them!

Leaf Launch

Very exciting news for this PCamp – Paul Young is launching his new product, Leaf!

From Paul: “Information overload is a problem that every product manager has.  Between email, phone, IM, tweets, status updates, geolocations, and keeping track of who knows what, just communicating can feel like a full-time job.  Social networking has amplified the problem – we now have access to more information than ever before – but how’s that working out for us?”

Does that sound like you?  You should attend his session, then.  I certainly will.

See you there!

Austin’s 3rd UnConference for product managers and product marketing managers is coming up on August 15t.  If you’re in Austin or can come to Austin, you should definitely plan on participating – it’s free, and a great opportunity to network, share, and learn.

ProductCamp – What Is It?

The first ProductCamp was started in the San Francisco Bay Area by Rich Mironov and the folks at Enthiosys in March 2008.  The largest one so far had 375 participants in the Bay Area, and the most recent one was last weekend in New York City.  As I type this, the ProductCamp Austin has 217 signups and 26 proposed sessions – less than a week after the announcement.

ProductCamp is a free, collaborative, unconference about product marketing and management.  ProductCamp is a bunch of smart, passionate people coming together to discuss, debate, and collaborate on the issues they face every day.  Everyone brings different experiences and leveraging that collective knowledge is what makes ProductCamp special – and something you can’t get anywhere else.

There are ProductCamps happening in more locations every day: San Francisco Bay, Austin, Toronto, New York City, Research Triange Park, Atlanta, Seattle, Boston, and maybe some more that I’m missing.  Someone created a web page that lists upcoming product camps (although it doesn’t provide any other information yet [if you're the owner of that site, comment below and let folks know how we can help connect the other city-specific sites to yours]).  There’s also a list of “all” past product camps on the barcamp.org wiki.  I know it is currently missing some of the events, but hopefully will emerge as the canonical list.  There’s also a newly created facebook fan page for all of the ProductCamps. It has a link to the Toronto ProductCamp fan page, and to the Austin ProductCamp fan page and hopefully soon, to any others that have been created.

If you know of a past ProductCamp that is missing, please update that wiki page (or contact me and I will update it).

Check out Paul Young’s recent article about Product Camp Austin and what to expect (if you haven’t attended one in the past).  Paul also gave a webinar yesterday about ProductCamp – with an introduction for new-to-ProductCamp people, and guidance for how to start a ProductCamp in your area.  You can download his slides and listen to the 40-minute audio track at the link.  Thanks to Ryma and Val Workman for hosting the webinar!

ProductCamp – How Does It Work?

Volunteers in each city put a lot of time into organizing the events, finding venues, soliciting donations to cover costs, encouraging people to participate, creating awareness of the events, setting up, tearing down, etc.  The event is free for people who attend – all that is asked is that people who attend help out.  Ideally, that means hosting a session (a presentation, roundtable, panel, workshop, etc) or participating in one; or it could mean helping out before, during, or after the session.

ProductCamp – What’s Going On?

There isn’t quite critical mass for any one site that aggregates all of the ProductCamp information.  This is an emergent phenomenon – and if you’re reading this after Jul 23rd 2009, the links above may not be the best ones.  For now, Twitter has emerged as the best way to see what’s going on with product camps.  The way to keep up is to search for hash-tags that the different product camps are using, find people who are tweeting about the product camps, and do some discovery leg-work.  Try searching Twitter for any of the following: productcamp, #pcamp, #pca09, #pct2, #pcampnyc, and certainly some others [add to the comments below].

ProductCamp Austin – How’s It Shaping Up?

As of this morning, for ProductCamp Austin Summer 2009 (main wiki page, facebook page, twitter search term, registration page, session-proposal page), we have 219 people registered, and 26 sessions proposed.  One thing we’re doing this year is capturing a demand signal from people as they register – specifically, what topic areas would they be interested in seeing presentations about.

We asked (are asking) people to select the three topic areas of most interest to them, from the list:

• Marketing
• Agile
• Requirements
• Product Strategy
• Career
• Other

Here’s a snapshot of the data at the moment:

Larger (and current) images of both graphs are maintained on the session-proposal page of the ProductCamp Austin Summer 2009 wiki.  This information is intended to inform the people who are proposing sessions – it is a demand signal.  There are no quotas by topic area, no requirement that sessions be in a particular area, etc.  Just information to help presenters pick a topic area (when they are undecided).

ProductCamp Austin – Finding Presenters

We’re driving participation “top down” because we’re creatures of habit.  However, what I personally believe will be more effective is for you to get people to host sessions at ProductCamp Austin.

• Do you know someone who is a great presenter with something to say about product management or product marketing?  Beg them to present.
• Do you work with people who have great insights about a particular area?  Bully them into participating in a panel (and volunteer to run the panel).
• Have you met someone who is facing a particular challenge and is looking for answers?  Convince them to organize a roundtable on the topic (and convince people with experiences to attend).
• Have you learned from someone who is a great teacher?  Cajole them into running a 50 minute workshop where people can learn something valuable and tangible.

Or of course, when you fit into any of these categories, volunter :).  And when asked by someone else, be flattered.  And say yes!

Paul Young (ptyoung on Twitter, Author of Product Beautiful) is the driving force behind organizing Austin’s product camps – thanks Paul!

For you product managers out there – here are a couple upcoming productcamp unconferences.  For you business analysts, here’s an excuse to do a little domain modeling and practice your UML class diagram skills.

Upcoming ProductCamps

There are at least four productcamp unconferences coming up in the near future.  I’ve been able to attend (and host sessions at) both of the productcamp Austin sessions, and they were great.  If you can make it to a session near you, you definitely should.  And if you go, you should help out – these are entirely free, and their quality directly relates to the amount of volunteer support that the attendees give.

1. ProductCampNYC – Jul 18th 2009 @ The Downtown Association, New York City, NY.  More info.
2. ProductCampAustin – Aug 2009 (exact day and venue TBD).  More info.
3. ProductCampToronto – (everything TBD).  More info.
4. ProductCampSeattle – Oct 10th 2009 @ Amdocs.  More info.

Check out the comments on this article too – as updates happen in different cities, I’m sure folks will post them here.

[Note: I updated the venue for the NYC product camp on 10 Jun 2009]

If you’re on twitter, you can search for #pcampnyc, #pca, for NYC and Austin productcamp info (respectively).  Or follow @ProductCampNYC.

Session Planning

One of the interesting things about productcamp is that it is a barcamp-style unconference.  That means it is free, and in theory, there is no centralized planning of sessions.  However, there’s a lot of planning that goes into having these unplanned sessions.

Roger Cauvin is one of the volunteers helping to organize the next productcamp Austin, with a focus on sessions.  He and I met over some seriously tasty Greek food at Tino’s Greek Cafe in Austin yesterday for lunch to begin planning for the sessions.  Our discussion focused around how the attendees will best benefit from the sessions, and what we can do to maximize that benefit.

One idea that came up was looking at addressing the frustration that people feel when there are two simultaneous sessions that they want to go see.  At previous productcamps, we used a very simple, on-the-fly scheduling approach:

1. We created index cards for each session and stuck them on the wall.
2. Each person had a few (3?) sticky notes, and stuck them under each session card.
3. The ones that got the most were lined up in the same room (to reduce conflicts in the popular sessions).
4. The rest of the sessions filled up the room/time slots without any particular optimization.
5. We did this sequencing in a couple minutes after everyone quickly “voted” with their post-it notes.

We learned, from “customer” feedback from the first two sessions that there is room to improve:

• People were still expressing frustration about “good session” conflicts.
• We also noticed a drop-off in attendance as people left before the end of the day – more attendees for earlier sessions.

So, if we’re going to improve session planning, one of the things we need to do is understand the details of sessions.  This is where domain modeling comes in.

We can create a UML class diagram that represents the domain of planning for (and attending) sessions.  This serves as an example of applying the business analysis techniques to gain insight into a problem domain before attempting to define a solution.

We know the following things about the domain:

• There are a limited number of rooms available for sessions.
• There are a limited number of time-slots available for sessions.
• Each session has a topic and presenter(s), and happens in a single room at a single time-slot.
• Each session has multiple attendees.
• Each attendee wants to attend multiple sessions.
• Each attendee has a prioritized list of sessions they expect will benefit them if attended.
• Each attendee can only attend one session per time-slot.
• Each attendee wants to maximize the benefit that they get from the productcamp.

[larger image]

The diagram above shows the relationships that will inform the design of any solutions.  For more on how to create UML class diagrams, check out our tutorial series on domain modeling.  One challenge of domain modeling is that there are often multiple ways to represent the same relationships.  With a goal of “understand the domain” – how would you model this differently?

A lot has happened over the last two months while we were building out nexus. One very interesting thing is the big changes at Pragmatic Marketing. The “800 lb. gorilla in the product management space” has re-branded some of their online assets and introduced new products and services. For some of our readers this is old news (April for at least some of it), for the rest, this is a cool update or introduction.

Preeminence?

As an extremely satisfied customer of some of Pragmatic Marketing’s training classes, I don’t know that I can say they are “the best.” I can definitely say that they are the best that I’ve worked with. Regardless, I was very excited when they announced several changes to their offerings in the product management space. I’ll try not to be too much of a fan-boy, and list a couple of the big changes that I’ve seen and liked.

As disclosure – I have positive relationships with several people at Pragmatic Marketing, and have had a couple articles published in their magazine – so I’m biased towards liking their stuff. In fairness, those relationships started after I attended their product management and requirements management training classes. That training out-shined all that I had taken in the past, and made me want to be proactive about building the relationships I have today.

New Look

First, their primary website (I guess they have multiple online assets) has been redesigned with a new look. The UI makes it much easier to find what you’re looking for, is cleaner, and better organized than before. One thing I particularly like is that their blog page is promoted more effectively – which will help drive more traffic to Steve and David and Adele’s blogs. They also include a very comprehensive list of the blogs that are really making solid contributions in and around product management.

New Branding

Their print magazine, formerly productmarketing.com is now The Pragmatic Marketer. Really a great magazine, happily still free, and now easier to download as a pdf when you want an electronic copy (much easier to search than a stack of paper).

New Services

Probably the most exciting update is that they are now offering services to help companies execute. There are more details after the link (this isn’t an ad for Pragmatic :) – but basically, you can now augment your team or project with services support to help your company execute. If their consultants are as good as their trainers, then this will be a home run for them. There’s a lot of opportunity for companies to get better at creating products, and “show me” or “do it with me” often works better than “tell me how” for helping people and teams learn.

Outsourcing is gaining momentum not only as a way to reduce costs, but as a way to create global teams. This trend is driving an increase in demand for business analysts. The change in perspective is driving companies to think about how they manage their business in new ways, and driving interest in new tools for business analysts to achieve these goals.

Hat tip to Ryan for his article on the year of the BA. The source that Ryan found is this yahoo article on 7 trends for 2007.

Trends

The role of the business analyst has emerged as a focal point for enterprises trying to wring more out of their automation-technology investments.[...] Ironically, outsourcing is feeding a frenzy to bring aboard more analysts. The experience of outsourcing IT has taught firms their technology-project specifications were in much worse shape than they believed. When companies would deliver specs to outside firms and individuals who didn’t have deep experience with their existing automation solutions, the knowledge gaps became painfully apparent.

Neal McWhorter, in the Yahoo article (emphasis ours)

We’ve all talked about outsourcing, and many of us have designed teams with different collaboration models to address the communication challenges.

This Computerworld article suggests that business analysts are one of 5 top areas for hiring, and business process management is one of 5 top technologies being explored.

How Business Analysts Adapt

Neal suggests that BAs will evolve their role and responsibilities to be something analogous to a product manager. We’ve been treating the roles similarly here – with the primary distinction being a single-customer focus for business analysts.

Neal mentions the IIBA and their new certification program as a likely means of setting expectations of and for business analysts. Barbara writes about the upcoming certification schedule for 2007.

Tools

We can’t overemphasize the need to be good at writing requirements first, and then using tools to become more efficient second. With that said, the increasing importance of business analysts drives the increasing importance of helping BAs be more effective.

Two areas where there are huge opportunities for improvement are business process modeling and requirements gathering/management.

BPMN

There are tools and vendors for BPMN solutions, and it looks like training is finally going to be more available in 2007. Bruce Silver is developing training that uses ITP Commerce as a tool provider. We’re currently designing a training course as well, built by extending the tutorial series we wrote last year, using visio stencils and a vendor-agnostic approach.

Requirements Management Software

Today, the space can be characterized as having the following solutions available:

• Spend a lot on an enterprise package, and mandate that all your projects use it, in order to recover the costs.
• Build your own solution, using spreadsheets, documents, email and other tools.

We expect this to change in 2007 too. Both of the approaches above can be cost ineffective for single-projects within a large company, SMBs looking to become more effective, and small consulting shops providing services to other firms. There’s a lot of opportunity here for the right solution.

Conclusion

Is it the year of the business analyst? The need is indisputable. Will the C-level execs act on it?

The BABoK (Business Analyst Body of Knowledge) lists 10 techniques for gathering requirements. Here’s an overview of each one. For more details, check out the latest Guide to the BABoK.

1. Brainstorming
2. Document Analysis
3. Focus Group
4. Interface Analysis
5. Interview
6. Observation
7. Prototyping
8. Requirements Workshop
9. Reverse Engineering
10. Survey

1. Brainstorming

Brainstorming is used in requirements elicitation to get as many ideas as possible from a group of people. Generally used to identify possible solutions to problems, and clarify details of opportunities. Brainstorming casts a wide net, identifying many different possibilities. Prioritization of those possibilities is important to finding the needles in the haystack.

2. Document Analysis

Reviewing the documentation of an existing system can help when creating AS-IS process documents, as well as driving gap analysis for scoping of migration projects. In an ideal world, we would even be reviewing the requirements that drove creation of the existing system – a starting point for documenting current requirements. Nuggets of information are often buried in existing documents that help us ask questions as part of validating requirement completeness.

3. Focus Group

A focus group is a gathering of people who are representative of the users or customers of a product to get feedback. The feedback can be gathered about needs / opportunities / problems to identify requirements, or can be gathered to validate and refine already elicited requirements. This form of market research is distinct from brainstorming in that it is a managed process with specific participants. There is danger in “following the crowd”, and some people believe focus groups are at best ineffective. One risk is that we end up with the lowest common denominator features.

4. Interface Analysis

Interfaces for a software product can be human or machine. Integration with external systems and devices is just another interface. User centric design approaches are very effective at making sure that we create usable software. Interface analysis – reviewing the touch points with other external systems – is important to make sure we don’t overlook requirements that aren’t immediately visible to users.

5. Interview

Interviews of stakeholders and users are critical to creating the great software. Without understanding the goals and expectations of the users and stakeholders, we are very unlikely to satisfy them. We also have to recognize the perspective of each interviewee, so that we can properly weigh and address their inputs. Like a great reporter, listening is the skill that helps a great analyst to get more value from an interview than an average analyst.

6. Observation

The study of users in their natural habitats is what observation is about. By observing users, an analyst can identify a process flow, awkward steps, pain points and opportunities for improvement. Observation can be passive or active (asking questions while observing). Passive observation is better for getting feedback on a prototype (to refine requirements), where active observation is more effective at getting an understanding of an existing business process. Either approach can be used to uncover implicit requirements that otherwise might go overlooked.

7. Prototyping

Prototypes can be very effective at gathering feedback. Low fidelity prototypes can be used as an active listening tool. Often, when people can not articulate a particular need in the abstract, they can quickly assess if a design approach would address the need. Prototypes are most efficiently done with quick sketches of interfaces and storyboards. Prototypes are even being used as the “official requirements” in some situations.

8. Requirements Workshop

More commonly known as a joint application design (JAD) session, workshops can be very effective for gathering requirements. More structured than a brainstorming session, involved parties collaborate to document requirements. One way to capture the collaboration is with creation of domain-model artifacts (like static diagrams, activity diagrams). A workshop will be more effective with two analysts than with one, where a facilitator and a scribe work together.

9. Reverse Engineering

Is this a starting point or a last resort? When a migration project does not have access to sufficient documentation of the existing system, reverse engineering will identify what the system does. It will not identify what the system should do, and will not identify when the system does the wrong thing.

10. Survey

When collecting information from many people – too many to interview with budget and time constraints – a survey or questionnaire can be used. The survey can force users to select from choices, rate something (“Agree Strongly, Agree…”), or have open ended questions allowing free-form responses. Survey design is hard – questions can bias the respondents. Don’t assume that you can create a survey on your own, and get meaningful insight from the results. I would expect that a well designed survey would provide qualitative guidance for characterizing the market. It should not be used for prioritization of features or requirements.

This is a bit of a potpourri post. Found some good stuff out there today, check it out.

The first IIBA Exam just finished in Orlando Florida. Barbara was one of the 16 business analysts who took it. Read about her experience!

Her post has inspired me to crack open my copy of the BABoK again, so here’s some great stuff that other people have written recently:

Understanding The Goal by Marcus Ting A Kee

Marcus presents what reads like a fantastic real-world example, even though he starts with “Suppose a client…” Real or imagined, it is a great example, well written. A single idea, presented crisply. Great quick read.

A couple presentations by Kevin Brennan hinting at changes for the next version of the BABoK. In the BA Fundamentals presentation, Kevin presents the definition of a business analyst in a really interesting way. He starts on p9 with the complete definition:

A business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems. The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals.

This definition feels pretty heavyweight (although rigorous), and it reads like an eyechart but check out what Kevin did on slides 12 through 19. Great way to present the fact that BAs do a bunch of things, and the quote above is already a shortened description of everything we do. Criticism retracted. I would like to figure out a more concise way to describe the BA role, but nothing comes to mind at the moment.

The IIBA (International Institute of Business Analysis) has just released version 1.6 of A Guide to the Business Analysis Body of Knowledge, or the BA BOK. This new release adds over 100 pages of content and is the first “essentially complete” version.

The IIBA was founded in 2003 with an exciting charter:

The IIBA is the independent non-profit professional association serving the growing field of Business Analysis. Whatever your role — requirements management, systems analysis, business analysis, requirements analysis, project management, or consulting, if you are involved in analysis for systems, business or process improvement, IIBA can help you do your job better.

The BA BOK

The business analysis (BA) body of knowledge (bok) is a massive 329 page pdf ebook available at the IIBA home page (pdf direct), that strives to include “everything” needed for the very broad role of business analysts.

The Business Analysis Body of Knowledge is the sum of knowledge within the profession of Business Analysis and reflects what is considered currently accepted practice. As with other professions, the body of knowledge is defined and enhanced by the business
analysis professionals who apply it. The BOK describes Business Analysis areas of knowledge, their associated activities and tasks and the skills necessary to be effective in their execution.

BA BOK 1.6 http://www.theiiba.org

Joining

The IIBA costs $95 per year in annual membership dues. There is an online forum for the IIBA.

End

Since we just pointed you to 329 pages to read over the weekend, we won’t write any more in this article. Have a great weekend!

Jerry Aubin and Joe Shideler of Seilevel will be giving their presentation, Beyond the System Shall – A Journey from Good to Great Requirements. Although this meeting is sponsored by the Austin chapter of IEEE, it is open to the public.

[Update: The meeting is from 6:30-9:00pm on Wednesday 15 February 2006]

If you were paying attention last month, this is the presentation that was delayed when we had our “ice storm” in December. The presentation has been rescheduled, so update your calendar.

From the summary:

“Today, only a small percent of IT projects succeed while the rest significantly under perform or fail outright. Seilevel will begin the presentation by delving into the statistics behind this statement and then move on to discuss how poor software requirements are a primary reason. The presenters will explore the root causes behind the problem and then provide suggestions as to how companies can improve the situation. […]”

I’ve had the pleasure of working with a few Seilevel folks in the past, and they are top-shelf. I’m looking forward to the presentation – you should make it if you can.

Update: Just realized that the link I included doesn’t have directions – check out the IEEE Austin calendar for directions to the event.