ProductCamp, the free unconference for marketing and product management, is teaming with the McCombs School of Business to return to Austin for its Summer edition!  ProductCamp is a must-go event for marketing and product management professionals.  ProductCamp is a free, collaborative,  gathering for interesting, smart people to network and learn from one another.  ProductCamps have been held in Silicon Valley, Austin, Boston, New York City, Toronto, Atlanta, with more in the planning stages.  This is Austin’s third ProductCamp, and will be one of the largest in the country.  If you are in Austin, or can get here, ProductCamp will be well worth your time.

ProductCamp Overview

If you’ve never been to a ProductCamp before, you’ll need to wrap your brain around a few new concepts.  First, ProductCamp is an unconference, meaning that everyone participates in some way.  For some people, that means offering a traditional lecture style 1-hour session on a relevant topic.  For others, it might mean being on a discussion panel, facilitating a roundtable, participating in a workshop, helping with planning, volunteering for venue setup, doing marketing activities, or managing the budget.  At ProductCamp, there are no attendees, only participants. Second, there is no direct monetary cost for ProductCamp to the participants.  The only cost is your investment in time and effort.  Third, the trappings of a traditional conference are gone.  There is no keynote speech, no thinly veiled sales pitches, and very little B.S.  As a peer-to-peer event, ProductCampers bring their very best stuff - and we keep each other on our toes.  ProductCamp is sponsored by corporations who enjoy supporting the marketing and product management communities, and often offer sessions of their own.

How ProductCamp Works

The first thing you do is register.  You’ll fill out a form asking you how you want to participate and what topic areas are the most interesting to you.  Next, check out the ProductCamp Austin website, and list of sessions offered by people like you.  Based on what you marked, you’ll be contacted by one of the ProductCamp Austin planning team leads to get your help.  For people interested in Marketing, you’ll post about ProductCamp Austin to your blog, or retweet @PCAustin’s tweets.  You’ll receive several emails over the next few weeks from the PCA Planning Team, and on the day of, you’ll stumble out of bed early on a Saturday to come to the McCombs School of Business at the University of Texas for your first ProductCamp experience.

When you walk up for registration, you’ll receive a badge, some goodies, and three small stickers.  A volunteer will take you to a wall where all of the sessions being offered by your peers are listed; there may be dozens of them.  You’ll be asked to “vote” by placing your three stickers under the three sessions that interest you the most.  This helps the PCA Planning Team understand the interests of the group and assemble the schedule.  When you’re done, you can grab a coffee and head into the auditorium for the Intro session.

In the intro, I will explain to you what ProductCamp is all about, and we’ll play some icebreakers to set the tone for the day.  Soon, the schedule will be done and posted on the website and on the walls, and you’ll go to sessions throughout the day, stopping just to grab one of the box lunches we provide.

At 3PM, everyone gets back together for a quick closing session.  Then we head to the bar to burn through any extra budget we might have!

During the day, expect to network with a ton of people.  You’ll meet product managers, product marketers, social media experts, marketing greybeards, executives, startup junkies, big company people, developers, agile experts, finance and ops people, and everyone in between.  You may leave with a stack of business cards, and should bring a stack of your own to give away!

ProductCamp Austin Details

When: Saturday, August 15, 2009

Where: The University Teaching Center (UTC) at the McCombs School of Business at the University of Texas at Austin (map)

Who: Anyone willing to participate!

How: Register Now! (space is limited)

Cost: FREE!

To learn more: ProductCamp Austin, Follow ProductCamp Austin on Twitter, ProductCamp Austin on Facebook

We’re looking forward to seeing you there!

Marcus chose to develop on RIM’s platform because of the size of the installed base and relative lack of competition for the app he was considering building (a long format audio player).  This validates a key tenant of becoming a platform I outlined in a past post:

The value of your platform to a partner and the likelihood of their developing to it is directly proportional to the amount of business the partner is able to capture through the platform.

However having a ton of potential consumers for your partners to service isn’t enough.  One of his first struggles was with RIMs SDK, specifically with regard to backwards compatibility:

All BlackBerry phones are java based, and there are two SDK options for developing software on them: MIDP/CLDC and BlackBerry specific APIs. The generic MIDP/CLDC route would work on any java based phone (or at least could be debugged on any java phone). Or you can opt to use RIM specific APIs that give you more BlackBerry specific functionality. Initially I leaned towards CLDC to maintain portability, but I eventually decided I’d rather take full advantage of the platform. I could always port it later if it came to that (if there is a later).

He also laments the lack of SDK features that would give his app the polish available from other platforms, such as the iPhone:

I envy the iPhone developers out there. From what I understand the iPhone SDK provides all sorts of pretty widgets that come pre-made to fit in with the platform. Right out of the box you get a clean UI that looks ‘modern’. To put PodTrapper 2.0 in the same league a significant portion of the code is dedicated to drawing lines, bezier curves, bitmaps and shading rectangles in just the right way.

There are other great quotes in there about Marcus’s interaction with users (his favorite part), how he chose to price his app, market it, and so on.  The point for Product Managers who are building out a platform is that we need to consider the entire lifecycle of a customer when we offer a platform, not just the API or SDK.

When you think about building out a platform, remember that for potential platform partners have several go to market choices.  They can build a standalone application and go to market direct.  Or they can come through yours or one of many platforms.  The size of your installed base (now their market), how frictionless you make sales, and how you take care of them in terms of billing and marketing are also key drivers of success.

I have led platform building projects at several companies, including my current role.  At each, we had an in-market product with an established customer base, and some number of interested 3rd party developers who wanted to extend our product with their own ideas.  Some of those projects failed, and some are (or will be) very successful.

Why Be a Platform

The allure of becoming a platform is easy to understand: your product gets the benefit of other companies investing time and treasure in extending its functionality for you.  Platforms are even more interesting when you factor in their positive feedback loop - as more developers add their products to your platform, the value of your platform increases to customers and attracts new customers, which increases the value of the platform to developers, in turn attracting even more developers.  Eventually, your platform has such a rich set of unique applications and services available through it, that customers have a hard time imaging getting the same experience through any other source.  They’re effectively locked in, not through force, but by choice.

Planning a Winning Platform

As you build a platform, you quickly understand that you have a new set of customers with new problems you need to solve: your development partners.  The brass ring that every company reaches for with a platform is OPM and OPT: Other People’s Money and Other People’s Time.  Some have made it work.  Others have failed miserably.  Many just fade into obscurity.

Platforms grow up in two ways: out of existing products, and as developer-to-developer programs.  Platform programs are dangerous because they are usually under-stated in time and resource commits - they have the potential to touch every part of your existing spaghetti code.  The urge in the development team to re-architect during a platform build is irresistible.  Product Managers: talk to potential partners, understand their needs and desires to work with you, find out which objects they want to interface with, and facilitate discussions between their developers and your development team.

Just as important when planning your platform is to understand your business strategy.  Me-too platforms almost always fail.  Look at your platform from your potential development partner’s eyes:

The value of your platform to a partner and the likelihood of their developing to it is directly proportional to the amount of business the partner is able to capture through the platform.

Questions to Answer:

• Are you building a platform as a competitive blunt, or to extend your core product?
• Does your company have the development resources to build a strong and deep API and SDK?
• Does your company have the development resources to support partners with integration questions
• Does your company have the marketing resources to publicize your platform?
• Can your product management team handle a massive increase in communications to partners whenever you make platform revisions?

Strategic Decisions

Business Model

Companies build platforms for two reasons: to increase sales of existing products (e.g. iPhone), or to make money on applications sold through the platform (e.g. Steam) - sometimes both.  One of the first decisions you need to make is will your platform be for free or for fee?

Free usually doesn’t mean that all partner apps are free, otherwise they’d have no incentive to develop, rather that the developer has the option to offer free functionality through the platform.  You can see this model in action today in the App Store, with free apps vs. their “pro” upgrades.  The advantage to free is that end users get functionality at no cost, which entices them onto the platform.  If you sell the platform, like salesforce.com, you can use free partner services to add value to your core app and sell more at no direct cost to you or your customers.

Another common model is revenue sharing.  In this model, the partner sets their own pricing and the platform owner takes a share of the top-line revenue.  For example, Apple takes 30% of all apps sold through iTunes.  You have to strike a delicate balance between the amount of sharing you demand from partners and the incentive for partners to develop through the platform.

Packaged resale is a model that we are using at Dell.  In the packaged resale model, we purchase apps in bulk from our partners to provide them with stability.  We setup volume tiers, much like a traditional distribution model with price breaks as we move up.  Then we turn around and repackage partner apps to our customers, pricing them as we see fit to be competitive.  The advantage of this model is that you get more control and flexibility with the pricing of apps through your platform.  The downside is that partners may fear losing control of their pricing models.

Open-ness

How open will your platform be?  Will you adopt a salesforce.com model of being an “open field,” meaning that there is a relatively low bar a development partner must pass in order to offer their application?  Or will you model your platform after the “walled garden” that is Apple’s iTunes App Store - and require that partners meet certain guidelines for functionality?  Or will you be more restrictive still and have an invitation only “planned community” approach?

The open field model means that you want a high volume of partners and you want to offer them low-to-no touch.  Facebook is considering opening their platform to partners and will probably adopt this approach.  Salesforce has used this model to great effect, attracting thousands of independent developers to their platform.

The walled garden approach raises the bar for partners enter your platform.  It may mean setting guidelines about what applications can or cannot do, like Apple has done.  Depending on how strict the guidelines you set, you can throttle partner demand - just be consistent in your application of the rules.

A planned community is another approach to platform building.  In this model, you go for quality over scale.  It may mean setting very strict requirements that partners must meet in order to play on your platform, such as security or functionality requirements.  The tradeoff is that you as the platform owner have more control over what is offered through the platform, and can stand behind any partner offering.  This model may be appropriate for co-delivered services or SaaS.

Customer Ownership and Branding

By virtue of owning the platform, you are bringing customers to the table.  Depending on the model you choose above, you may allow developers to use their own brand, co-brand, or re-brand partner apps as your own.

If you are co-delivering a service through your platform with partners, co-brand or re-brand works well.  This model is popular with telecommunications companies who use their broadband platforms to offer re-branded partner services such as online backup or anti-virus.

Factors for Success

As you consider launching a platform, there are key metrics you should consider.  Number of partners, number of applications or services, revenue derived from the platform are all good starts.  Even before you set metrics, there are some key success factors that you can whiteboard that will let you know at a high level if your platform will fly.

The most important consideration that will make your platform succeed or fail is how much business a potential partner can capture from the platform.  All of your other strategic decisions must line up to the reality of this number.

Next is the strength of your target partners.  Depending on the platform model you choose, you may be targeting anyone from individual developers to large, established ISVs.  The key is that you match your target partners with the level of investment required by a partner to develop to your platform.  You can’t ask independent developers to operate a service out of SAS70 Type II data centers, for example.

Consider the problem that end customers solve by buying partner applications or services through your platform.  If there is marginal added value to buying through you, your platform will not be sustainable and you will churn customers, and eventually collapse.  Remember when every new PC you purchased had an AOL icon preinstalled on the desktop?  There was no value to customers in purchasing AOL this way, in fact it annoyed most people to see it there, and created a negative perception of the “platform (the PC).”  You don’t see that as much anymore.  You have to add something other than a channel to the customer - Apple adds a great user experience, Saleforce adds great analytics to hard-to-manage data, Steam offers digital gaming management so you never have to find a CD again.

Finally, if you have created value for the customer, value for the partner, and settled on a model that makes sense, you are ready for the last analysis: how will you and your partners make money?  Is there enough margin to revenue share - or are you willing to forego revenue sharing and offer your platform for free to partners in order to get more apps or services in order to move more of your core product?  This analysis is hardest and will require talking to lots of potential partners and field testing your pitch.

Good luck, and let me know how it goes.  Happy platforming.

If you’re interested, drop me an email with your resume. No recruiters pretty please!

UPDATE: I missed it, but Scott Sehlhorst of Tyner Blain, another Austinite is also pictured.

What if we didn’t refactor our roadmap…again?

What if we didn’t spend time fighting for headcount from HR, phones from IT, or travel from Finance?

What if we ignored all of the built up processes and built something awesome anyway?

What if instead of 20 hours of meetings, you spent 20 hours blogging, tweeting, and talking with potential customers online?

What if we stopped trying to connect our internal projects and started connecting with customer needs?

What if we never used another quantitative report again?

What if all of the analysts disappeared from the Earth tomorrow?

What if we became a brand?

What if we became THE brand?

What if employees sought us out?

What if customers sought us out?

What if we created a product category?

What if we scaled 10, 100, or 1000x next week?

What if we built a Billion dollar business?

What if?

This is a great interaction because it illustrates the rift between marketing and product management.  First, I suspect that Godin isn’t really saying that for any given company it is better to have an inferior product.  He’s saying that for a marketer it is better.  I’ll go a step further - for a great marketer (which Godin is) it is better.  The first question I always get from Marketing is “what are this product’s differentiating features?”  Lazy marketers love to have the leading product in a market because they just need to maintain the status quo.  A great marketer likes the challenge of winning with a product that doesn’t necessarily win on all of the features.  It was a painful lesson the first time I learned that it is not enough to have the best product on the market, you must also have great marketing to let people know about it and get people excited about buying.

Have you and your competitors reached near parity?  Do you differentiate using price?  Does sales laugh when you point out differentiating features of your product because those features don’t really matter?  Do you wordsmith new “features” just to have something the other guy doesn’t on your product slicks?

We’ve had “winning product solve customer problems” beaten into our heads as product managers.  In every market there is a set of features that solves the customer’s problem that everyone’s product has, e.g. the “baseline” feature set.  This is the barrier to entry that any new competitor must meet to play in your market.  You use features above that baseline to differentiate your product.

In commoditized markets, the size and relevance of the features above the baseline shrinks to near zero.  The importance of marketing increases as differentiation shrinks.  Eventually the barriers to entry become so low that nearly anyone can enter, at which point operational efficiency becomes the most important aspect for success, and marketing becomes primarily packaging and pricing.

One of my mentors used to work as a brand manager in consumer goods for P&G.  He told me a story about laundry detergent that is a great metaphor for where we are heading in technology.  The laundry detergent market is highly commoditized.  There are dozens of companies selling everything from luxury to economy detergents and everything in between.  P&G sold several different brands under different names, aimed at different customer segments.  The ability to segment and target customers in consumer goods is astounding - they have it down to a fine science.  “College educated Caucasian mothers under 40 with 3 kids living in a major metro area with a household income of >$125,000″ is an example of the level of their segmentation.  If you go to the grocery and turn the detergent boxes on their side and read the ingredients, they are all nearly identical.  The major differences are pricing, and packaging.  It turns out that the mother above just doesn’t feel comfortable buying the “economy” brand, and will instead opt to pay more for Tide to basically buy a prettier box.  That much is obvious; the really interesting piece was the product differentiation.

People buy the pretty box but they aren’t dumb.  They open the box and see the white powder, the same stuff in the economy box, and they resent paying more.  P&G experimented with lots of options, and ended up adding green crystals to the Tide powder.  What did these crystals do?  NOTHING.  People assumed that they got their clothes cleaner or smelled better.  They were there to make you feel better about buying a nicer box with “power crystals.”

Over time, if you take several companies competing for the same market, they will commoditize it even without product management.  You don’t need product management to copy your competitor.  Lots of companies that have identified operational efficiency as their core competency are happy to let other companies take the first mover risk and be the second mover into a market.  If all of those companies have good product managers, they’ll be talking to the same kinds of customers and potentials, hearing similar problems, and developing similar products and features.  Price will become the differentiator and the market will commoditize.

I see a lot of green crystals in technology today.  There are lots of products where the baseline has risen to “good enough” and the differentiating features either aren’t compelling enough to justify paying for them, or customers just don’t care.  On the cost side, we’re squeezed by free and open source products.  What role does the product manager play in a commodity product?  I hypothesize that the markets where companies need product managers will shrink at roughly the rate that those markets commoditize.

What do you think - are we entering the post-Product Management economy?

You might be a Product Manager if:

1. You’ve created a roadmap through 2015
2. You can’t remember working less than 70 hours a week
3. You’ve lost your hair (if you haven’t consider yourself warned!)
4. At your annual customer summit, you stay late to setup and test products for the next day while Sales runs up a historic bar tab
5. You used to be a programmer but were too extroverted
6. You used to be a salesperson but were too introverted
7. You use customer interview techniques with your spouse to discover the root cause of their problems so you can build a “solution” (”That’s interesting…tell me more!”<smack>)
8. You wake up at night worried about getting your product’s feature-set right or hitting your ship date
9. You find competitive and win-loss analysis fun (ugh, I can’t believe I just realized I find those things fun)
10. You walk through the store and look at products thinking “what problem does that solve?”
11. You do a SWOT analysis before making any major purchase
12. The last thing you do before you go to bed and the first thing you do when you wake up is to check your email
13. You’ve ever written “The System Shall…“
14. You never have less than five #1 priorities
15. You’ve sat behind the one-way mirror at a focus group
16. One or more of the following groups is pissed at you: Sales, Development, QA, Tech Support, Marketing, or Operations. Special bonus if you get all at once.
17. You enjoy writing requirements that constrain easy way out from the Programmer.
18. You’ve actually learned how to herd cats.
19. You own an iPhone.
20. You wonder how the iPhone product manager prioritized all the possible features.
21. You wonder how many engineering hours it took to create a new feature in your favorite web app.
22. You try to envision the next 3 design updates for any product you see.
23. You think in Use Cases.
24. You’re always looking for an alternative flow of events.
25. You can’t live without OmniGraffle or Visio.
26. You had to reset expectations with management, customers, engineering, and finance.
27. You had to produce a WW product forecast for sales since they are too busy to do it.
28. You enjoy watching “How It’s Made.“
29. You plan “features” for your children and have a “roadmap” for their skill growth
30. Your wedding included a powerpoint presentation.
31. Major life events require a MS Project file.
    
32. You get “phantom buzzing” in your pocket when you forget your Blackberry.
33. You’ve talked to more customers in the last month than all of your executives combined.
34. Your marketing person said “you’re technical…explain this to me like I was 10.” then, “…now like I was 3…”
35. You know what all of these are: MRD, PRD, BRD, Functional Spec, sprint, scrum, CAB, spiff.
36. Your favorite question is “why?”
37. Your favorite application is Excel.
38. You’ve built your own product P&L template in Excel to save time.
39. You’ve used your P&L template across multiple companies.
40. You know what the “analyst dance” is, and you’re definitely a PM if you’ve done it.
41. You know what your customer is going to say before they say it.
42. Your spouse knows who your 3 biggest competitors are by name.
43. You’ve flown on every major (and some minor) airline this year.
44. You’ve used Twitter, LinkedIn, or Facebook to connect with a customer.
45. You’ve dreamt about competitive kill sheets.
46. You’ve been to ProductCamp
47. You’re the one your CEO comes to when he/she really wants to know how things are going.
48. “They” remembered your revenue commitment but not your product’s funding.
49. Everyone thinks they do a part of your job.
50. You’ve ever had to explain to a founder or executive why customers don’t want their great new idea.
51. You’ve been asked for the revenue impact of deleting a single feature.
52. You’ve been held accountable for Development’s schedule slips.
53. You’ve been the person that everyone brings the hard questions to at the trade show booth.
54. Caffeine is one of your primary food groups.
55. You spend more time with your development counterpart than your spouse.
56. You write a blog about Product Management…gulp!
    

Special thanks to my twitter friends: @joshua_d, @imusicmash, @chriscummings01 for contributing to this list!  You can follow me on Twitter, too.  Happy New Year!

What is ProductCamp?

ProductCamp is an unconference.  An unconference takes the old, stogy idea of a conference and turns it on its side.  Instead of corporations paying for boring keynote speakers talking and waving their hands, you have the participants in the conference leading all discussion sessions.  ProductCamp is a meritocracy, or perhaps a participatocracy - anyone can lead a session on any topic relevant to product management or marketing.

At the first ProductCamp, we had sessions ranging from career advancement for product managers, to intellectual property discussions, to working with Agile development organizations, to working effectively with Sales and Executives, to user interface design.  ProductCamp attracts a broad and diverse crowd of smart people who “get it,” so the networking is really good and the discussions are rich and rewarding.

Describe the ProductCamp Experience…

It’s Saturday January 24, 2009 and you wake up way to early for a weekend and head down to the UT campus.  You park and walk up to the College of Communications and follow the signs to ProductCamp.  As you ride the elevator up to the 4th floor, there are three other people with you looking confused.  “Are you here for ProductCamp?” “Yeah, this should be interesting…”

You exit the elevator and see a registration table with people milling around it.  As you make your way to the front, you recognize a few familiar faces from other companies.  You give your name to the PCA volunteer at the table and he hands you a badge and a goodie bag with a PCA shirt in your size.  You make a beeline to the coffee.

As you get your coffee, you notice that ProductCamp has attracted all types - managers, developers and engineers, academics, startup junkies, and everything in between - and these people are talking to one another.  Someone is rambling about their startup, and other person is educating a small group about Twitter: “ProductCamp has its own Twitter ID, here’s how you follow it…”

After chatting for a few more minutes, a PCA volunteer calls everyone into one of the rooms.  The studios at UT are huge, with 40 foot ceilings and have seen much use and abuse over the years.  As you walk in, a volunteer hands you three post-it notes and you wonder “why just three?”  The room has a projector showing a “Welcome to ProductCamp” slide.  Someone gets up and introduces themself as a ProductCamp planner and thanks the sponsor for breakfast.  Next, someone gets up and gives a short minute intro on the open grid scheduling process.  You listen as you’re told to put vote with your sticky notes under the three sessions you’d most like to attend, which are listed on the back wall.

You head to the back wall and read the session names, offered by people just like you.  You recognize a friend-of-a-friend’s name who is giving a session about “Connecting with Customers.”  That sounds good - you use one post-it note.  You see another session about “Agile Product Management.”  Your engineering team is moving to Agile so that might be a good session to attend, and use your second note.  As you step back to consider your third note, you see a dozen other people doing the same thing, and people feel geniuely torn about what to vote for - there are so many good sessions to choose from!  Finally, you put your last sticky on a session called “Career Building in Product Management and Marketing.”

You walk back to your seat and see the PCA volunteers start to rapidly count the votes.  Someone gets up and explains that they are determing which sessions are most in-demand so that they don’t overlap on the schedule.  While the volunteers assemble the schedule, a ProductCamp planner gets up to talk about what ProductCamp is and why everyone is here.  He says things like “ProductCamp is for starting conversations, not finishing them - it’s OK if these discussions spill out onto email, blogs, forums, twitter, or facebook.” “Learn from each other’s collective experiences, but challenge each other - speak up if you hear something that you agree or disagree with.”  You think “wow, this is definitely not a normal conference.”

The planners announce that the schedule has been set, and the crowd huddles around the posted schedule to see which sessoins they are going to attend.  You notice that your favorite sessions are at 10-11, 1-2, and 2-3, and you fill your schedule with other sessions you think sound interesting, including a roundtable discussion.  You refill your coffee and head to the first session in Studio 4E…

As you walk in, you see 20 other people looking at each other and wondering how this is going to work.  The session leader is welcoming everyone and making introductions, and you see her slide projected with the session title “Roundtable: Working with Sales.”  The session leader gives a quick facilitation of 1-2 slides and kicks off the discussion by talking about a recent scenario where she introduced a new product to Sales and was immediately met with hostility from the Sales team.  The questions fly quickly “was the pricing right?” “how is your relationship with them normally?” “How did you explain the value of the product?” “Does that product solve a customer problem?” “Did you just repackage one of your existing solutions?” “Is sales compensated correctly on your product?”  The Q&A continues and the facilitator guides the discussion into new areas: how to be effective with your sales leadership, how to get sales buy-in for new product launches, how to end-of-life a product with sales, and so on.  Through the discussion you furiously type notes out on your laptop as you try to capture some of the great ideas that the team is generating.

The hour-long session feels like it is over as soon as it begins.  You wish it could continue, but you only have a few minutes to get to your next session.  You quickly introduce yourself to the facilitator and a few other people you were impressed with and exchange business cards.  You notice that they have their Twitter ID’s on their badges and quickly follow them on Twitter.

You go through two more sessions before lunch and meet several impressive people.  You think “I need to keep these people on file because they might be good if I’m hiring or looking for a job.”  You grab a plate of catered lunch and sit down with some of your new friends and talk about the sessions they attended so you can get the scoop on what you missed.

After lunch, you hit 4 more sessions.  By the end of the day, you are spent, physically and mentally.  As everyone filters out, people are already talking about the next ProductCamp and what sessions they plan to offer, and you think that maybe this isn’t so hard, and you’ll offer a session next time, too!  A group breaks off to do an official ProductCamp happy hour, and you join in few a few drinks.  The week after ProductCamp, you email some of your new connections to grab lunch - it’s great to keep the network fresh.

I hope that this gives you a taste of what to expect at ProductCamp.  After running one, I was very excited to lead another, and have high hopes for ProductCamp Austin Winter 2009.  I look forward to meeting you at ProductCamp!

Go Register for ProductCamp!

Most companies do an employee satisfaction survey at least once per year.  I have seen at least 10 of these surveys and in every single one, the top employee concern was “communications.”  The telephone game is bad, but when you observe that effect in two directions (executive level down, individual contributor level up) you get what I am calling the spin cycle - because you can spin for weeks on end just to get everyone agreeing before work on a project even begins.

“Go do’s” and Executive Fiat

Ideally, a Product Manager has the time to do research, write requirements, and bring products to market that meets the needs of customers.  Conditions on the ground rarely allow this process to happen cleanly.  In larger companies, there is the concept of the “go do.”  “Go do” means that for whatever reason, the executive team needs you to execute a tactical task.  A go do could be implementing a certain feature, choosing a certain partner, or attacking a certain market segment.  Usually go do’s are influenced by big picture concerns such as existing lines of business, strategic partners, or even keeping the board happy by interacting with another part of their investment portfolio.

A CEO I used to work with called mandates from management “ruling by Executive fiat.”  That is a great phrase, and reflected his desire to avoid Executive fiat unless completely necessary.  Sometimes you need to get in and break a tie on the team, but in most cases the right answer should be obvious.

Go do’s and ruling by fiat are dangerous because they remove decision making from lower levels of an organization.  Most go do’s come without explanation - it’s just “go do this.”  In the absence of reasoning behind a “go do” decision, teams project reasoning through their own world view.  The development team thinks management’s directive to choose a specific partner is a mandate to use .NET over Java.  The marketing team believes that implementation of a certain feature represents a new strategic direction for the company or product and aligns marcomm efforts accordingly.  The downstream effects of a fiat decision can be disastrous.

Sources of frustration

Management resorts to “go do” orders for several reasons:

• Trust - they don’t believe in their team to do the analysis and come to the right decision, so they co-opt the thinking
• Sensitive Information - they have access to sensitive information, such as M&A, that for business reasons can’t be made available to the team
• Scope - they have line-of-sight to other lines of business that their segment is not concerned with addressing
• Speed - they perceive the team and their decision making process as too slow, and want to short circuit process and jump straight to the “right” result

Employees get frustrated with mandates because they don’t understand the thought process behind the decision making process.  As a Product Manager it is possible that a mandate will be in direct conflict with the goals and roadmap of your product!  Reconciling this gap is a key communications hurdle that Product Management must step up and own.

The worst consequence of the spin cycle happens when employees take a go do and immediately start to execute based on their understanding of management’s ask.  They go off for weeks or months, working on a solution, bring the result back to management who says “wait…THAT’s not what I wanted!”  The communications cycle has broken down completely in both directions, fostering more mistrust between management and employee.  Since the employees didn’t “get it right,” management’s perception of employees as do-ers and not thinkers is reinforced, resulting in more and more mandates.  Employees  become jaded, stop asking “why,” and mumble about how management doesn’t know what they want.

Breaking the Spin Cycle

Product Management and Marketing sit in the unique position between the executive and employee layers, and are positioned to facilitate better communications across the entire business.  High performing teams are built on trust,

To truly break the spin cycle, first control the conversation.  When you are asked by management to “go do” a feature or partnership - ask “why?”  Some executives are insecure and take this as an affront to their power or management style, but good management will provide you with the reasoning behind the decision.  If they balk, explain that you will need to communicate this decision across the organization, including the deprioritization of other work in order to get this project done, and that being able to effectively explain the decision will help speed up the work.

Next, illustrate the impacts of a mandate.  Executive teams are notorious for “forgetting” about all the work in-progress, expecting new work to get tossed on the pile and not change the scope or dates on ongoing work.  Show how stopping current project, and starting something new will change release dates for everything.

Finally, be able to show strategic impacts of the decision.  If the executives want to mandate the usage of a specific partner, you need to understand that partner’s capabilities and  how that decision will change your roadmap.

How do you address this issue?  Please reply in comments!