Why is innovation hard for large organizations?

I came across an interesting post on this topic, and I have to say, that I really agree with what the author, Kareem wrote. In it he mentions three key reasons for the general failure of large companies to innovate:

1. They must protect their current business
2. Too much bureaucracy or too many stakeholders in the process
3. They don’t provide the proper financial incentives for innovation.

I’m sure most of us who have worked in larger companies have experienced the first two. I’ve also seen a lot written about the first two points related to big company culture, management practices etc. People today cite Apple as a great example of a company that has figured out how to deal with those two points.

I want to spend the rest of this post talking about point 3, which I think is critically important and of which I have not seen as much writing.

In any general cross-section of employees, there will be a small subset who can be deemed as truly entrepreneurial and innovative. A lot of them probably come from the Product Management and Engineering teams! And most of those people are smart enough to understand the value they can bring to a company as well as to themselves if they can deliver a successful product to market.

The problem is, in a typical large company, the ROI proposition for bringing an idea to market is completely skewed in favour of the company. Kareem says it really well in his article:

People are incredibly quick to learn which behavior is rewarded in any system. If you want to innovate, there are two options: remain in a system that pays out an annual salary and a relatively meager bonus for your awesome product. Or, strike out on your own, and build a product that might have a significant pay off, while living off savings or investment.

Now imagine a large technology company that has set aside a large pool of money for acquisitions. That number could be in the hundreds of millions of dollars or even higher. The company wants to make acquisitions that help bolster it’s current market position as well as take it into new (likely adjacent) markets.

There are probably lots of innovative startups out there, working on new products that are potential acquisition targets. Now as the company is out there evaluating the market and potential targets, and then spending big bucks to acquire those companies (likely making the founders of those companies wealthy), what are the innovators inside that company thinking?

They are thinking:

“Hey, how do I get me some of that?”

Now imagine if the company took, say, 5%-10% of that acquisition pool and used it to create a fund that would invest AND if successful reward new innovative products by employees. The structure of how this would be done would have to be worked out carefully so as to ensure transparency in the process of who got funded, and clarity in how success was measured and rewarded, but in theory it is possible.

I can think of at least one model, where an quasi-independent group would review the ideas and decide how to provide an internal equivalent to angel/seed funding to get the project to a stage where it could be evaluated in detail. This model would be no different than what one would face if they took their idea to an Angel or VC for funding.

Regardless of how it is done, there could be significant advantages for the parent company by doing this.

• It sends a very clear message that existing employees can see significant upside if they are major contributors to success in the company
• It significantly reduces the potential for “brain-drain” in the company, by stopping some of the best innovators from leaving to form new companies outside
• It provides a lower cost option for the company to “acquire” new innovative products than going out to market and paying a premium for “hot” acquisitions.

The return for the employees who go this route would be lower than what they might get if they were to strike out on their own, but then again, the risks they would face would also be lower. They could leverage many of the large company’s resources as well as the large customer base of the company. While some hardcore innovators may not like this situation, I’m pretty sure many others would.

Imagine an incubator, funded by the large company (and possibly by other external investors as well) that would provide the environment for these ventures to develop, grow and ideally graduate and become successful. If the venture is one that the large company wants to acquire, they can do so relatively easily given their stake in the company. If they don’t want to acquire the company, the market can decide the value of the company and like any other VC, they can regain their investment (and much more) by some kind of liquidity event.

What do you think of this? Is it possible for large companies to develop incubators for their own employee’s to create innovative products and companies? Or are there other issues and complexities that would make this concept more likely to fail than succeed?

Saeed

What’s the opposite of “analysis paralysis”?

I was discussing something with Alan today and during the conversation he said something like:

Well, you don’t want to get stuck in analysis paralysis but you don’t want to go to the other extreme either.

So, I though to myself, “What is the other extreme? Does it have a name?”

We all know that “analysis paralysis” is the state where one cannot make a decision because they get stuck trying to figure out all the possibilities. I’ve seen it happen in people a few times, and it can be painful to watch, as they hum and ha and try to figure out what is the right decision.

On the other end of the scale are those situations where a decision is made by someone with little or no debate, research or analysis, and the person is convinced this is the only, or possibly the best of all options. This to me is the opposite of analysis paralysis.

I call this state “utopia myopia“.

Essentially, a very limited perspective is used to achieve a theoretically ideal outcome, ignoring other perspectives or outcomes. This is very common when discussing new product ideas or solutions to problems. There is always a small number of people or sometimes a sole individual in the group who has a very strong opinion of what to build and why, and will not change their view, nor will they agree that additional research or investigation is needed before a final decision is made.

I once worked for a company where the CEO had a real disdain for market research and said at a planning meeting:

There’s no value in doing research. By the time you do your research, you could already have finished building the product.

Needless to say, that company was not very successful at all.

So, that’s my contribution to the English language this week. Use the phrase if it applies. For example, if someone is stuck on some idea and won’t budge. say:

You know what, you’re suffering from utopia myopia, and you really need to broaden your perspecitves.

Watch how they react, and drop me a line and let me know what kind of response you are getting when using this phrase.

Saeed

Subscription Pricing vs. Enterprise Pricing

A question was recently posted in a number of Product Management discussion groups. It read (in part):

…I am working on adding a subscription based pricing model for our product. I have read articles that talk about the “rule of 17″ that suggest a monthly payment should be 1/17th of a perpetual license fee.

I have structured the models so that the “crossover” between the License fee model (including maintenance streams) and the subscription model was sometime in the first half of year 2. I have seen 3 year models as well.

What do you use or what have you seen? Have you offered both model for a time and if so what are the conflicts (if any) that arise?

It can sound very tempting to provide a subscription alternative to your own enterprise software, but you need to think beyond simply price, and think through the evaluation model, the sales model, the expense model (you’re now taking on the cost of hosting/operations), and how you go to market, convert leads etc. I’m assuming here that the subscription pricing is for a hosted or SaaS version of you current on premise software?

The approach to take is to start from first principles, and define the value proposition for the end user or customer.

There is a real tendency if you already have an on premise solution to:

1. ensure you don’t cannibalize the revenue coming in from that solution
2. use the pricing of the existing solution to determine the price of the SaaS version

If you go down either path, the subscription solution is likely to fail.

The first one will always put the existing product ahead of the subscription based product. This is what happened with Siebel on Demand. The existing business had to be protected from encroachment or cannibalization by the on demand business and it hampered the on demand business significantly. Your company will really need to shift it’s thinking to manage this well.

The second is tied to the first, but also ignores a really great opportunity you have to define a true value-based and scalable pricing model that could generate more revenue and have significantly higher customer retention than the current pricing model.

Spend some time with the target customers and understand the value proposition from subscription based pricing, and do some price sensitivity testing with them. This should really help you understand how the pricing can provide value. It may also show that there is no appetite for subscription based pricing, but I’m assuming that is not the situation in your case.

One of the interesting things about subscription pricing is that the money will often come out of OpEx budgets in companies whereas for traditional enterprise pricing, it will come from CapEx budgets. Now a dollar is a dollar, usually, but whose budget it comes out of make s a big difference in how people perceive price.

Additionally the pricing model has to take into account the true value delivered by the software. It is very easy to think of per seat per month or per user per month pricing. It certainly worked for SalesForce.com. But the beauty of subscription pricing is that you are not tied into that model or one model for that matter. But whatever you do, keep it simple! Enterprise pricing is ridiculously over complicated. Use the subscription pricing exercise to address that problem.

Figure out what the key units of value are from a customer perspective and use those for the pricing. There may be multiple models based on user scenario. While you don’t want to force existing customers to move to subscription pricing, you’ll have to figure out a transition pricing model to move them over (and possibly back) if needed.

Think of it this way. If one of your competitors came out with a competitive subscription based offering to your current product, would they simply take your pricing and apply the “rule of 17″? No, they’d figure out a compelling value proposition and pricing model and use that as a weapon against you. Get one up on your competition and do it before they do.

Saeed

P.S. Here’s an article on subscription based pricing that may be helpful.

Survey says….

Last week I asked the question, How much revenue for each PM in your company? with a link to a survey. The survey was intended as a “quick and dirty” sampling of data to get some numbers related to revenue ratios for Product Managers. Truly a more analytic survey would be in order to get more broad-based industry wide data. Perhaps our friends at Pragmatic Marketing or Forrester can take this task on.

The survey asked the following questions:

1. What kind of company do you work for?

• Public
• Private

2. How many product managers are there in your company (or division of the company in which you work)?

3. What is the annual revenue (in millions of $) of your company (or division of the company in which you work)?

4. Which of the following best describes the type of technology your company (or division in which you work) primarily provides?

• Software
• Software as a Service (or hosted applications)
• Hardware (e.g. servers, routers etc.)
• Software and Hardware (e.g. hardware appliances)
• Other

5. Which of the following best describes the main target customers for your company’s products or for the product of the division in which you work?

• Consumers
• Businesses
• Government
• Other

6. If you answered Other in question 5, please specify the type of business.

7. Do you have any questions or comments about this survey?

And here are the results. Thanks to all those of you who responded. Note that I’ve rounded all revenue numbers to the nearest million.

Total Number of Respondents: 67

Break out by Company Type

• Number of Public Companies 26
• Number of Private Companies 41

Number of Companies by Technology Focus

• Software: 29
• Hardware: 3
• Software and Hardware: 17
• SaaS/Hosted: 15
• Other: 3

Number of Companies by Customer Focus

• Business:50
• Consumer: 12
• Government: 4
• Other: 1

Annual Revenue Range for Public Companies:

• Smallest: $10 Million
• Largest:$1.5 Billion
• Average: $341 Million

Annual Revenue Range for Private Companies:

• Smallest: $0-1 Million
• Largest: $1 Billion
• Average: $58 Million

Average Annual Revenue (in $millions) by Company Type

Average Revenue	Private	Public	All
Hardware	30	250	177
Software	28	310	135
SW and HW	79	283	187
Saas/Hosted	19	600	174
Other	338	–	3

All

58

341

168

NOTE: The “All” column/row is the overall average for that column/row. e.g. 177 represents the average revenue for ALL hardware companies.

There is significant breadth in the data here. If we exclude the “Other” row, the Public companies have revenues roughly 10 times that of the Private companies.

Average number of Product Managers by Company Type:

Ave. # of PMs	Private	Public	All
Hardware	1.0	3.8	2.8
Software	3.4	13.1	7.1
SW and HW	5.4	9.1	7.4
SaaS/Hosted	3.5	11.0	5.5
Other	4.7	–	4.7
All	3.8	10.7	6.5

Even though the Public companies had roughly 10x the revenues of the private companies, the number of product managers in Public companies is only about 3x that of Private companies. While I don’t have data to support this conclusion, my own experience having worked in both public and private software companies is that these numbers are not far from reality.

Average Annual Revenue (in $millions) per PM by Company Type: (Calc 1)

Ave. Rev. Per PM	Private	Public	All
Hardware	30.0	66.7	62.4
Software	8.3	23.7	19.1
SW and HW	14.7	31.1	25.5
SaaS/Hosted	5.4	54.5	31.8
Other	72.4	–	72.4
All	15.2	31.9	25.8

NOTE: Averages were calculated as overall average. i.e. sum of all revenue per category divided by sum of product managers for those companies.

Average Annual Revenue (in $millions) per PM by Company Type: (Calc 2)

Ave. Rev. Per PM	Private	Public	All
Hardware	30.0	55.0	46.7
Software	9.5	22.9	14.6
SW and HW	9.7	44.2	28.0
SaaS/Hosted	5.1	75.3	23.8
Other	32.1	–	32.1
All	10.5	40.8	22.2

NOTE: Averages were calculated as average of ratios. i.e. each company’s revenue/PM ratio was calculated and an average was taken of all companies falling into each bucket above.

Comparing Calc1 and Calc2

As you can see that while there are some similarities in the numbers between Calc1 and Calc2, there are also some significant differences. For example, while the corresponding Software numbers are close to each other across the tables, the Private-Other numbers are very different (72.4 vs. 32.1). This is because Calc1 will skew the data if there are large outliers in the data. e.g. The Private-Other only has 3 data points and they vary widely in revenue, thus skewing the Rev/PM.

Calc2, takes an average of ratios, so that widely ranging revenue (or PM) numbers aren’t going to skew the data as much. I’ve combined those two tables into the following table that gives a range for each bucket.

Ave. Rev. Per PM	Private	Public	All
Hardware	30.0 - 30.0	55.0 - 66.7	46.7 - 62.4
Software	8.3 - 9.5	22.9 - 23.7	14.6 - 19.1
SW and HW	9.7 - 14.7	31.1 - 44.2	25.5 - 28.0
SaaS/Hosted	5.1 - 5.4	54.5 - 75.3	23.8 - 31.8
Other	32.1 - 72.4	–	32.1 – 72.4
All	10.5 - 15.2	31.9 - 40.8	22.2 – 25.8

So, how do these numbers compare to the situation in your company? Drop us a line…

Disclaimer: Take the data for what it’s worth. I’m not a statistician. The data set is small (67 completed surveys) and when subdivided by Public/Private and Software/Hardware/SaaS/SW+HW etc. the numbers of data points in each bucket can be quite small and thus the error bars around any calculations can be significant. Don’t blame me if you use this data and bad things happen to you. But if good comes from using the data, drop me a line and send some of that good karma my way. If you do use this data in any presentations or other publications, please reference the blog. Remember, even on the Web, plagarism still means stealing someone else’s ideas and presenting them as your own.

Saeed

How much revenue for each PM in your company?

Someone asked me a question recently and I couldn’t find an answer on the Web, so I decided to ask all of you for help.

After reading my article, “You can never have too many Product Managers“, the person asked me whether I knew of any published numbers that provide guidelines for the number of product managers a company should have relative to it’s revenue.

The answer is, unfortunately: it depends.

It depends of the stage in the lifecycle of the product, the market, the kind of customers etc.

To get data, I need your help. In return for 30 seconds of your time — that’s all it will take I promise — I’ll collect the data and share it back with all of you in a future post.

Survey is closed. Click here for the results.

Thanks.

Saeed

Seth’s Advice for Product Managers: Quit Now

Seth Godin gives some advice to real estate agents. Allow me to paraphrase his advice for Product Managers:

Here’s my best advice (everyone knows a product manager or two, so feel free to forward this along).

Plan A: You should quit being a Product Manager. I’m serious.

Quit being a PM. Get a job doing something else.

Some of you have been waiting to hear that. My pleasure.

…

The ones that are left, that’s you, can consider Plan B:

If you’re not going to be able to make a living by helping sales, by checking to see which bugs have been fixed, by using the never-ending ream of support calls to answer, then what are you going to do? Whining is not an option.

In fact, I think this is an extraordinary opportunity for you.

As [Seth] wrote in The Dip, you’re either the best in the world (where ‘world’ can be a tiny slice of the environment) or you’re invisible.

So become the best in the world at understanding your customers. This means being Draconian in your choices. No, you can’t also do a little of this or a little of that. Best in your world means burning your other bridges and obsessing.

You become the source of information, the watercooler, the person to turn to.

“I have no time!”

Of course you have that time available. Remember nine months ago when you were three times as busy with sales calls as you are now? Invest that time in building up your expertise and becoming the person people who don’t even like you turn to for insight.

The opportunity is to reinvent the way you interact with current users, with prospects, with the mildly interested and with your past clients. The opportunity, in other words, is to stop waiting around for the phone to ring and instead figure out how to do what you do best… connect users and developers in a way that makes them both confident.

Some of you will stick with the standard business card with the standard photo, the standard office and the standard feature request strategy and the standard approach to making the phone ring. It’s going to be a long haul if that’s your route.

I’m betting, though, that the best of you will end up with a product that will survive, thrive and prosper. Best time to start is right now.

OnProductManagement plagarized!

Hi,

I’m sure this happens all the time on the web, but I just ran across 2 - likely related - blogs on Blogspot that have lifted my iPhone vs. IPod Touch article verbatim.

http://informationfun.blogspot.com/2007/10/iphone-vs-ipod-touch.html

http://hitechtech.blogspot.com/2008/02/iphone-vs-ipod-touch.html

Any suggestions for how to handle this? If imitation is the sincerest form of flattery, does plagarism imply something better?

Saeed

Product Managers need time to breathe…

I’m going to make an assertion here, and please correct me if I’m wrong.

I believe that the vast majority of software product managers are running full tilt in their jobs, caught between the short term tactical cross-functional activities (working with Dev, Sales, Marketing etc) that are thrust upon us, and the important long term market research, business and product planning activities that are fundamental to managing successful products.

Do you agree? Disagree?

Companies want Product Managers to innovate, take bold steps, define new products, enter new markets, yet at the same time deal with all the day to day operational issues that arise and need to be dealt with. I’m surprised more product managers don’t burn out after a few years. Or perhaps they do, and like the trees in the forest, we’re not there to witness them fall.

There’s an interesting post on Innovation at IdeaChampions.com. Entitled, INNOVATION is an INSIDE JOB, the article makes several good points, but the key one is:

Organizations do not innovate. People innovate. Inspired people. Fascinated people. Creative people. Committed people. That’s where innovation begins. On the inside. The organization’s role — just like the individual manager’s role — is to get out of the way.

I couldn’t agree more. A lot of companies want to be innovative, but unintentionally put barriers in front of those best suited for the job by never really getting out of the way. It’s difficult to be inspired, fascinated and creative, if you are constantly required to focus on the short term needs of other teams. How can one extricate themselves so they can get out and learn and think and postulate and research and conclude and innovate?

One solution which I wholeheartedly support is to create Product Management teams who are responsible for delivering the goods. The teams can be structured in different ways. You could combine business focussed PMs with technically focussed PMs or you could split the PM responsibilities across functional areas of larger products. There are likely other ways to split up the responsibilities.

But the goal is to get to a level where the teams can work in a pipeline or leapfrog manner. i.e. while one team (team A) is focussed on bringing a release X to market, another team (team B) is out researching release X+1. Once release X is GA, team A can focus on researching release X+2, and team B is working to get release X+1 developed and out the door.

Now, before you start thinking — hold on a minute, how many product managers are we talking about here? — ask yourself a couple of questions:

• What impact does Product Management have on your company?
• Could it have a higher impact on optimizing Development, Marketing and Sales with a small increase in headcount?
• How well could your company execute if you had deep market knowledge, clear understanding of user AND buyer needs, through competitive information and requirements that were complete, accurate and timely?

If you answered, “Significant”, “Yes” and “Much better than we are now” to those questions respectively, then think about defining product management teams in your company. Give them the time and tools they need to do a first-rate job, and then hold them responsible for it.

Challenge the teams to leapfrog each other in functionality, performance, scalability etc. The teams should view each other in a competitive manner. Why? Because your competitors are looking at you this way. They are trying to leapfrog you. They are looking at your weaknesses and trying to exploit them. They are going to try to out market and out sell you. Why not look at yourself the way your competitors look at you and beat them at their own game?

This may sound a bit unconventional but it works. Intel did this for several generations of their microprocessor chips. They had parallel teams working on successive generations of chips. Each new generation of CPUs (e.g. 286, 386 etc.) was to eclipse the previous generation. Not only did Intel make significant performance gains from one generation to the next, they kept upstart competitors like AMD playing a constant game of catch up.

Both AMD and Intel are successful companies, but which would you rather be? Why not take a lesson from an industry giant like Intel and apply it to your company?

Saeed

Forrester on Product Management

I’m quite happy to report that Forrester Research has started a blog covering Product Management:

http://blogs.forrester.com/product_management/

Here’s link to the bio of the analyst writing the blog: http://www.forrester.com/rb/analyst/tom_grant

IMHO, this is a very positive development. Research firms like Forrester, Gartner etc. are typically descriptive vs. prescriptive. i.e. when they start covering a space or a market, it is because it exists and is growing and deserves focus, vs. spending time covering something that has not yet reached a minimum critical mass and may grow in the future.

As an example, I worked for a number of years at Informatica in California. We were a recognized leader in the “ETL” (Extract-Transform-Load) market. But we really saw the market as having moved to what many called “Data Integration“. It wasn’t until several years later that the analyst firms created specific research practices related to Data Integration.

So with Forrester looking at Product Management, this probably means that firms selling products such as Requirements Management tools will be getting more analyst coverage, and perhaps Forrester will host events or conferences related to technology product management. It will be interesting to watch.

So,welcome Forrester, and let’s hope the other research firms see the light.

Saeed

What’s the deal with Personas?

The CrankyPM recently posted a good little rant on personas. It’s drawn some interesting comments from both sides of the persona camp (PCamp? ). BTW, I’m totally jealous as she snagged a great title — Persona non grata — for her post.

I’ve been incubating the following persona related post for a while, and thought now a good time as ever to finish and post it.

There’s been a fair bit of writing related to personas as a tool for better understanding users and their requirements. Adele Revella has The Buyer Persona blog, and Bonnie Rind has her Product Personas blog. And of course, the accredited father of the persona concept for product design is Alan Cooper. Cooper’s firm has a number of persona related articles on their site. Perfecting your Personas by Kim Goodwin provides a good overview for those who are interested in understanding the basics.

She starts:

A persona is a user archetype you can use to help guide decisions about product features, navigation, interactions, and even visual design. By designing for the archetype—whose goals and behavior patterns are well understood—you can satisfy the broader group of people represented by that archetype.

This makes complete sense and whether one is explicitly familiar with personas or not, it’s what most Product Managers tend to do, some better than others.

Later Kim writes:

There is seldom a one-to-one correlation between personas and job descriptions. In some cases there will be multiple personas with the same job description; in others, a single persona can represent people with a wide range of jobs.

Thus for a single job — say an administrator — there could be personas representing new administrators who need lots of prompting, and experienced administrators who prefer command lines and know exactly what they need to do. Again, not much to debate here.

Later on Kim writes:

You can also add life to the persona by using environmental details to reinforce important characteristics. For example, if someone tends to be incredibly busy at work, don’t just say he’s incredibly busy; instead, say there’s a sandwich on his desk that he’s been trying to find time to eat for three hours.

Now this is where things get interesting, and this is the issue that Cranky fixates on in her post. And to be honest, it’s really hard to disagree with Cranky. Imagine the look on a bunch of developers faces as you start laying out the persona, describe their environment, their goals, their workflow, and the fact that a sandwich has been sitting on their desk for 3 hours.

Might as well stamp the words — Marketing dweeb — across your forehead and then tell them you’re going to get a soy latte at the brasserie. First of all, I’ve yet to meet a development team that cares about these kinds of details. They don’t want to know that Albert, the community college grad who provides DB2 database administration support likes to watch Ren and Stimpy videos while he waits for nightly database backups to run.

They also don’t want to know that Sachiko, the business analyst, has an MBA from a second-tier Midwestern university, is planning the details of her upcoming marriage, and thus doesn’t have time to conduct proper and formal analyses for the new CRM system that is needed.

These are all completely unnecessary details in the B2B context. For consumer software or products, these details may be very important.

A while back, I worked on a new Administration Console for an enterprise middleware product. The product itself was in widespread use, but there was a real push to make it “enterprise ready”, which meant that things like security and role based permissions were important.

The developers spoke about the target user — “the administrator” — in very vague terms. There was also confusion around the fact that some users of the product could act as both administrators and operators depending on the circumstances.

We needed clarity on this and a way to distinguish who did what, when and why with the product, and who the target would be for the new Administration Console. So, we decided to talk to customers to get some raw data. After a number of customer visits and calls, we determined the following:

• There were four major “administrator” roles within our customer base
  • Network Administrators
  • Infrastructure Administrators
  • Application Administrators
  • Operations Administrator

• These four roles were generally consistent across customers, though responsibilities crossed over between roles in different customers
• Administration teams were structured very differently across organizations
  • Some customers had administration teams with global responsibilities
  • Others had teams with specific geographic focus (e.g. Americas, APAC, EMEA)
  • Others had teams responsible for specific applications

From these and other findings, we came up with specific definitions of the roles. Here’s the definition of the Infrastructure Administrator which we decided was the target user for our Administration Console.

An infrastructure administrator is concerned with a specific set of hardware and software running on that hardware. This set of hardware/software is usually domain specific. I.e. it is assocated with a particular enterprise application, such as Siebel, PeopleSoft, an external web application or some other system.

The infrastructure administrator’s job is to ensure that the particular hardware and services, particularly the services, they are responsible for are operating efficiently and that any general maintenance, such as application data backups, server shutdowns etc. are managed in an efficient way.

In the context of our product, an infrastructure administrator is responsible for starting/stopping repositories, configuring servers, performing repository backups etc. In most cases, but particularly with small to medium installations, the infrastructure administrator also handles inter-repository migration of metadata. i.e. they do the deployment from development to test, and test to production.The infrastructure administrator is the primary user of the Administration Console, though from our discussions it is clear that they do not need to use it everyday.

The developers really understood this description. We had similar ones for the other three types of administrators, and throughout the development of the Administration Console, we regularly referred to these roles, their descriptions and other findings from our research when questions arose as to what should or shouldn’t be part of the console. Notice there is no mention of personalities, habits, level of disorganization on someone’s desk or anything that detracts from the role and it’s focus.

So, what’s deal with Personas? Technically nothing, unless you insist on using them with engineers or other people who just couldn’t give a damn about all that extraneous “marketing fluff”. A big part of Product Management is communication, and speaking in the language of others. If engineers don’t “grok” personas, don’t force them down their throats.

Saeed