Monthly Archives: December 2006

Holiday Semi-Vacation


I’m taking a vacation thru the end of the year.  Hooray!  We’ve already written a series of short articles about migrating a development team to an agile process.  Those articles will appear over the next several days – we hope you enjoy them.

When I can get online, I will respond to comments and emails – thanks folks for the increasing levels of interactivity – you’re making Tyner Blain exactly what we want it to be – a place where folks share and learn and succeed!

Have a happy holiday and a fantastic new year, and enjoy the series

To Buy, or Not To Buy. To Build? is the Question

builder fresco

Should we buy this application, or build it in house? Maybe some of each. How should we make that decision today?

Build, Buy, or Both?

This is somewhat of an age-old debate. IT departments were initially chartered with cost-reduction initiatives. Automate this process, reduce errors in that process. For some companies, IT departments stopped becoming a cost-center and started becoming a profit-center. Initiatives began to appear that were designed to enable top-line growth, not just cost-reductions. Enable this sale, encourage that one.

As companies objectives for the use of software evolve, we should probably revisit the age old question of build versus buy. But there’s also a middle ground – do some of both. Almost all enterprise software is intended to be customized. Many open-source products are created as extensible frameworks. Companies package applications into suites, and distribute stacks (collections of open-source software, pre-assembled and validated to work with each other).

The game hasn’t changed, but the players have. We should revisit this question.

Their Answers

This question has been asked and answered before. Collecting the answers that have been out there for a while:

  • Packaged product vendors tell us to buy. “You should focus on your area of expertise, your products, and leverage our area of expertise, our products.” A very compelling argument. For any given IT department, any particular project is a one-off project. The IT department of an air-conditioning unit assembler/manufacturer is going to have little or no experience in developing a CMS (content management system). A community college is unlikely to have billing and invoicing system experts in-house. The argument is that it will be too expensive for these inexperienced teams to work through the hidden complexities and difficult problems of developing these systems. A vendor of one of those systems will be staffed with experts in that particular system. The packaged software vendor will have been distributing the cost of solving those problems across multiple customers. No one can build Quickbooks for $300. A company is better off buying this packaged software and tweaking their accounting system to use it.
  • Many IT workers tell us to build. Any of a number of factors cause people to present this argument. We should dismiss the specious arguments that all fall in the “not invented here” category, or are self-serving. I once worked with a client who’s motto was “Invent.” Their IT team took that to heart, and perhaps selected to build when they should have bought. I also worked with a client who’s motto was “Think.” I believe their IT department did a better job in thinking about when and when not to invent. There are certainly situations when building is appropriate. There may not be a product available for purchase. There may be intellectual property considerations – if Dell is looking to further reduce their lead times or increase their inventory turns, they may want to do that work in-house, simply to prevent outsiders from learning what they already know. In these cases, the IT department does have expertise to rival or surpass the software vendor.
  • Enterprise Software is some of each. Enterprise software vendors apply a modified version of the packaged software vendor’s argument. They will point out that the hidden problems are so complex, or the scope of the solution is so large, that no independent IT team should even attempt to solve it. And they generally have a point. But this argument can be weakened. Thirty years ago, no one would consider running a business on Quickbooks. Accounting practices are different for every company. Intuit decided that there was an underlying theme of commonality, and built a company around that theme. Their customers compared the costs of adapting their accounting to match the software with the costs of custom-developing a solution (or paying an enterprise software vendors to customize their “starting points”) and decided that process change was cheaper than product purchase. Enterprise vendors still have an advantage when there are no alternatives that are “close enough” to their solutions.
  • Open Source is All of the Above. Open source solutions are “free*.” Companies can download and install free software that attempts to be equivalent to packaged software – install and use. Subversion is a great example of this – a company can install subversion as a source code control system, or they can purchase a solution like MKS, Clearview, or Visual Source Safe. Open Office competes with Microsoft Office. AVG Anti-virus competes with McAffee. Open source solutions may be development environments like Ruby on Rails. They are designed to reduce the cost of building a solution. The more interesting open source solutions are frameworks and stacks. Drupal is as much a framework as it is a CMS. A company can build a solution by enhancing a “free” framework with a combination of free modules and custom-developed modules. A company can build this solution to run on a free operating system, a free webserver, and a free database. A vendor may sell a “stack” of free packages – certified by the vendor to work together. Some stacks are even free – like LAMP (linux + apache + mySQL + php). Combine a LAMP stack with Drupal, and you may have 90% of the functionality of an enterprise software solution. A small amount of (additional) customization can get you to the same end result with a much smaller price tag.

*Free, in this context means that other costs are relatively equivalent to other choices – training to use a new process, or new software, or both, is roughly the same for all of the choices.

Hat tip to Francis Dion, for his recent article on this subject. Here’s his opener:

Back when I was a corporate IT staffer, I used to hate arguments such as this one, confident in the belief (like everybody else in this business) that we could do better than anything that existed out there.

Now that I am a bit (ergh, quite a bit :-) more seasoned, my views on this topic have changed radically.

Buy vs Build

Finding Your Answer

Ultimately, each decision will have to be pragmatic, and will depend on a number of constraints and factors that are specific to your business. Assuming you have already ruled out the infeasible products and approaches that you deem to be “too risky”, you are left with a set of solutions. Now filter those based on your constraints:

  • Financial Constraints – are you bootstrapping a startup, or trying to burn through some VC cash?
  • Time Constraints – do you have a year to get something built, or will you be sacrificed in a month if your solution isn’t live?
  • People Constraints – do you have people with the skills to build or extend and support custom development. If you answered yes – ask yourself again – do you really?
  • Intellectual Property – will this software be leveraging or enhancing your core-competencies? Is your business model dependent upon differentiation in this space? How much would it hurt if your competitors (inexplicably) started doing the same thing?
  • Vision – your company may have a strategic vision for developing tools to support it’s ongoing business. Not sure why, but maybe you do. Don’t change your nature because of math. Stick to it, and good luck with that.

Select By Value

Once the constraints have narrowed the range of possibilities, we have to make rational decisions based on ROI.

We start by understanding our requirements – why are we building or buying in the first place? We then narrow our possibile choices to those that would achieve our goals.

We look at the TCO (total cost of ownership) of each solution approach. This includes purchase price and maintenance fees (if any), development costs (in-house or outsourced), and training / process re-engineering costs (if any).

We combine the expected gains and costs to identify the expected value for each approach.

We look at the timeline for how quickly we can get a solution in place, and incorporate that timing into our ROI analysis – leveling the playing field by comparing the net present value (NPV) of each alternative.


There isn’t a one-size-fits-all answer. Generally speaking, look at your options, apply the constraints of your reality, then do the math.

Successful Product Managers – Seven Traits

key to success

Michael Shrivathsan just posted an excellent article on his experiences of the seven traits of successful product managers. Absolutely awesome article. Thanks Michael!

Michael has a lot more details, but here’s his list:

There you have it. My list of seven traits shared by successful product managers:

  1. Communication Skills
  2. Leading Without Authority
  3. Learning Skills
  4. Business Acumen
  5. Love for Products
  6. Eye for Details
  7. Routine Product Management Skills

Seven Traits of Successful Product Managers

Usually, we like to add our thoughts to other people’s articles. This time, we have to just add this to the “wish we wrote that” list.

Flashback: A Year Ago This Week on Tyner Blain [2005-12-16]


Everything I Needed To Know I Forgot In Kindergarden 2005/12/13


Why do we stop asking why? When we’re grown-ups, and toddlers ask “why?” for the hundred-thousandth time, why do we say “because I said so?” I’m not on a crusade to enlighten the toddlers of the world (ok, I am in my corner of the world, but that’s not the point of this blog). If you stop to think about the best people you work with – developers, project managers, CIOs, you’ll find a common pattern – they ask “why?” all the time. Somehow, they never stopped asking “why?”. Why?

Getting Past The Suck Threshold 2005/12/14


Kathy Sierra writes a great post in her blog, Creating Passionate Users, that talks about the requirement to make things interesting.

The driving objective is to accelerate the user adoption curve – which Kathy calls the Kick Ass Curve. Any user is initially forced to focus on the tool, and not the task. The better the design of the tool, the faster they can master it, forget about it, and focus on the task at hand.

Use Case Series: Introduction 2005/12/16


Use cases can be difficult to talk about, because they immediately invoke so many different preconceptions and prejudices. High school English teachers know that some words aren’t just words – they are symbolic, and represent ideas. They had us write essays like “Who do I think is a hero” and everyone picks a different person, for different reasons.

Product Manager Salary Survey – More 2006 Results


Trying to unearth more trends in the 2006 salary data from the Pragmatic Marketing annual product management and marketing survey. In this article, we look at total compensation relative to the revenue of the managed products, the company size, and the company age. More fun with numbers.

Product Manager Compensation vs. Product Revenue

The survey asked:

What is this year’s expected revenue target for the primary product you manage, if any? (in millions of US$)

We created a scatterplot of the compensation responses relative to the product revenue targets:


[larger image]

There wasn’t an obvious trend in the data, other than noting that the highest paid respondents all had responsibility for multi-million dollar products. Note that the product revenue scale is log-based.

Maybe higher salaries correspond to larger companies.

Product Manager Compensation vs. Company Size

When we look at the average compensation of product managers versus the size of their employers, we see the following:

company size

[larger image]

For companies that are under a $100 million in annual sales, there seems to be a trend that larger companies pay better. This might be reasonable as a characterization of the SMB (small to medium business) space. Larger companies may have a similar curve, but lower. There isn’t enough data to support this characterization – call it speculation.

Product Manager Compensation vs. Company Age

Do younger companies pay better? One might hypothesize that product managers are better appreciated by new / young companies, for whom a single product failure can mean failure of the company. Alternately, “old” companies have been around because they have successful products, and therefore reward their product managers more handsomely. Who would be right?

Here’s what the data shows:

comp v age

[larger image]

Nothing obvious (to us) here. What about combining some of the above?

Company Size and Age

If we characterize the companies by the two dimensions of age and size, we can map out a grid and see if there’s any interesting trends that are visible.

First, we look at the number of responses within our data, mapped against the two dimensions.


We have a reasonable spread of data, with only one empty box (11-20 year old companies under $1 million USD in sales). Almost 20% of our respondents work for well established companies with more than $1 billion USD in sales.

Looking at the average total compensation for product managers in each box of our chart, we see the following average salaries:

grid data

OK, that reads like an eyechart – let’s make it more visual.

graphics of compensation

The green bars represent higher than average averages. That is, the average total compensation in a given cell is higher than the average of all of the data.

  • Younger companies (under 20 years) at the high end of the SMB space ($50-$100 million USD sales) pay more, on average, than the average of all companies.
  • Larger companies (over $250 million USD sales) generally pay above the average rate for product managers.
  • Companies with a “youthfull but established” age of 11-20 years also tend to pay above the average.


There aren’t any obvious and dominating trends in product manager compensation versus company size or age. There are some subtle trends in the data.

These trends may not provide clear guidance about who to work for, but that doesn’t matter. All politics is local. The right product, team, and culture will make more difference in quality of life than a 10% pay bump.

The extra slicing of the data may help you make a more compelling argument in your next performance review or salary negotiation.

Overdoing Personas

people on needle

Its easy for us to overdo almost anything. Kim Goodwin offers some good advice about how not to overdo it when using personas as part of our software development process. Hat tip to Steve.

Personas are the representation of archetypical users of our software. They are used as a component in an interaction design approach to developing software. Start with our earlier article How To Create Personas for Goal-Driven Development.

Then check out Kim’s article about how to not overdo it (and good practical advice about what is important).

Thanks Kim for the great advice.

Actor Hierarchies And Then Some

actor hierarchy

Actor Hierarchies give us an overview of the people who will interact with the system. We can extend this model to provide a visual indication of how use cases are distributed through the organization. Further, we can leverage a hierarchy to show how use cases are rolled out to the users – a targeted communication for our stakeholders.

Actor Hierarchy

A hierarchy is a model for representing the classification of things. The example we probably all learned first is the hierarchy of phylums, used to classify animals (dogs are a kind of canine, which is a kind of mammal, which is a kind of animal).

The hierarchy is a presentation of classification. Imagine that we were developing a GPS system for after-market addition to cars. As part of determining the requirements for our product we would want to identify the users of our product. In use cases, these users are the actors. We might identify casual drivers, taxi drivers, and couriers as the potential users of our product. What we need to do is organize these users in a logical way. We can use a hierarchy to do this.

car and driver hierarchy

All of the actors in the above diagram are “Car Drivers.” Some are casual drivers, and others are professional drivers. There are also taxi drivers and couriers, both of whom are types of professional driver.

If we’re using interaction design, we can build a similar hierarchy for our personas.

Mapping Use Cases To Users

We can create a simple table that shows how our targeted use cases map to our users. We can present the information in our table so that the hierarchy is evident. The pretty pictures above are cool and all, but harder to put in a table

actors and use cases

Communicating A Delivery Schedule With Use Cases

The top of the hierarchy is Actors, branching into sales and accounting as two types of actors. With sales, we have a salesperson and a regional manager. Each column represents an actor, and the groupings of columns give us the hierarchy.

Each row represents a use case. We could put “X”s in each cell to represent which user can do each activity. We get more value from our document by populating each cell with the release-information for each use case (see the cited article on scheduling releases for details).

Evolving Use Cases

Yesterday we presented the concept of evolving use cases. We can use this approach to make communication of this evolution even more effective.

Imagine that we were evolving the Review Regional Orders use case to have an initial version in the Q2 release, and a second version in the Q3 release. In the first (Q2) release (of the functionality that enables the use case), we have all of the features needed by the regional manager. In the second (Q3) release, we add the functionality needed for corporate accounting to use the use case. The diagram above sort-of implies this – but it could be much more effective.

Our chart would look like the following:

evolving use case chart

The highlighted region shows that we are going to manage two different versions of the Review Regional Orders use case. Version 1 is released in Q2, and version 2 is released in Q3.


Actor hierarchies allow us to organize our use cases and understand how our users interact with the product. We can combine this documentation model with the concept of evolving use cases to provide powerful communication.

Incremental Delivery and Evolving Use Cases

books started by selling books. Their initial use case was “Sell books online.” The vision was always “Sell everything” – hence the name. But they started with a simple use case and evolved it.

Evolving Use Cases

Roger Cauvin had two very interesting posts (here and here) about versioned use cases – where he describes the idea of delivering a particular use case incrementally. Roger proposes incrementing use cases along two dimensions, features and constraints. Good articles – check em out.

Use Case Evolution

We think these are great ideas, and can be combined with the notion of scheduling releases with use cases, timeboxing of incremental delivery, and Kano-driven prioritization to structure the most profitable product roadmap. This is the most profitable approach for two reasons. First – delivering the most valuable features first is more valuable for our customers – allowing us to charge more for the increased value. Second – incremental releases of software provide incremental revenue more effectively than single releases.

Evolution By Feature

Amazon provides perhaps the most well known software example of evolving a use case by features. A former CEO of mine told a story allegedly told to him by Jeff Bezos. This CEO was known to use fiction to make a point, so I have no idea if the story is true. Here it is paraphrased:

Jeff walked in on the end of a planning meeting with the founding team of Amazon. They put together a big proposal that was as thick as a phone book, detailing how they would sell everything online – books, CDs, DVDs, housewares, groceries – everything. Jeff picked up the plan, weighed it in his hands, and then threw it across the room and into the trash can and said “how about we just sell books?”

The idea is solid, even if the story isn’t. Jeff wanted to start with books. Essentially, a feature-constrained version of the vision for the company. Over time, Amazon added products, allowing for an evolving version of the use case.

Another famous example might be the Model-T Ford – “Any color, as long as its black.”

Evolution By Constraint

Use cases getting better over time is the easiest way to think about this. Improved usability, improved performance, and increased scalability are all good examples. started with an ASP 1.0 server, allowing them to support 12,000 concurrent connections – then later upgraded to ASP .NET to support their current 500 million hits per month traffic levels – on a single webserver and single DB server! Now Markus is gearing up for a billion page views per month.

Evolution By ‘More Is Better’

The exact same semantics as the gradually tightening constraints on a non-functional requirement apply here. This is no different than evolving constraints, when the underlying parameter or attribute is represented as a non-functional requirement.


Thanks Roger for sharing a really good idea.

[Update 2006/12/13] We just wrote an article showing how to communicate evolving use cases with an actor hierarchy.

Product Management Glass Ceiling Cracked

glass ceiling

Pragmatic Marketing released their 2006 product manager survey results. At first glance, there appears to be a huge disparity in compensation between male and female product managers. When we look in more detail, the evidence does not support that conclusion.

History of Data

We took a cursory look at the 2000-2005 product management survey data back in October, and The Cranky Product Manager has done a similar analysis including the 2006 results. Unfortunately, we and she have both jumped to a couple conclusions about salary inequality.

Earlier Misinterpretations

Here’s the conclusion we jumped to…

Notice also the unreasonably large gap between blue (female) and maroon (male) overall compensation data.

Tyner Blain, Oct 2006

And today’s interpretation…

On the brink of the year 2007, female product managers in the US and Canada only make 87 cents for every dollar their male counterparts make. For the SAME JOB.

The Cranky Product Manager

Good Questions

The Cranky PM asked some good questions about the analysis:

So why is this happening? The Cranky Product Manager wants to find out…. Her top-of-the-head hypotheses include the following:

  • The women respondents skewed younger or less experienced than the male respondents?
  • The women respondents tended to be less technical than the male respondents?
  • The women respondents are in worse-paying industries than the male respondents?
  • Sexism? (which might be increasing over time?)

The first three hypotheses could potentially be ruled out by slicing and dicing the raw survey data.

The Cranky Product Manager

And we respond…

Responses By Gender And Experience

We started by looking at the experience level of the respondents to the survey (435 of 439 respondents specified either maleness or femaleness). We start by filtering to ignore the four respondents that did not provide gender data.

In the survey, two questions were asked about experience:

  1. How many years have you worked in a technology role?
  2. How many years have you worked in your current role?

We found that some respondents considered themselves to be non-technical (for example, 15+ years in their current role, 0 years in a technology role). We decided that using the larger of the two responses would give us the best proxy for years of experience.

The following chart shows the number of respondents by answerable experience range in years.

response by experience

[larger version]

What immediately jumps out at us is that there are far more male respondents at the higher levels of experience. We may be inclined to conclude that there are far fewer female product managers at these experience levels, but we can’t. All we can conclude from the survey data is that more males responded to the survey, not that more males are in the role.

Salary By Experience

We would expect salary to rise with experience, although it surprisingly plateaus at the 3-5 year mark


[larger version]

With just this data – higher salaries at higher experience levels, combined with a higher number of male respondents with more experience – we would expect to see higher salaries for males. And that’s exactly what our cursory examinations showed. What about looking at the “gender gap” when normalized for experience?

Product Manager Salary By Gender And Experience

When we split the salary data by experience across gender lines, we see something interesting.

by gender and experience

[larger image]

For product managers with more than five years of experience, the women who responded to the survey are out-earning the men. The only large disparity we see in either direction is for people with less than a year of experience (about 1% of our respondents).

Almost 85% of the respondents have 6 or more years of experience, and for those groups, the women have higher compensation than the men.


The soundbite analysis appears to show women having markedly reduced earnings relative to their male peers in 2006.

Looking at the next level of detail, we see that within ranges of comparably experienced product managers, women earn more than men For the experience ranges that represent the bulk of the respondents, women reported about 5% higher earnings than men as product managers. We also saw that product managers with more experience tended to earn more than their neophyte peers, although experience beyond the five year mark (for our experience proxy) did not seem to have much affect on earnings.
These data were obscured by the larger number of male responses within those higher-earner categories.

Although an earnings disparity may exist, the data from this survey does not support the argument.

Flashback: A Year Ago This Week on Tyner Blain [2005-12-10]


Agile Requirements 2005/12/05


James Shore, in his blog – Successful Software, writes about the requirements process, and in particular, an Agile approach – his recent post lists the set of articles that he has written on the subject.

Ideavirus – Marketing By Word Of Mouth 2005/12/06


When you launch a new software product, or start a new blog, or a website, one way to get the word out is by viral marketing.

It’s Not Business, It’s Just Personal 2005/12/08


Having the best powerpoint presentation (thanks to Presentation Zen and Beyond Bullets, this is possible) is not sufficient to persuade. You have to craft a personal message. And you have to be interactive, and adapt your presentation as you present – maybe even discard it entirely, and craft the key points of your message into a conversation lead by the person to whom you are presenting.

A Picture Is Worth A Thousand Requirements 2005/12/08


Object oriented analysis and design (OOA/OOD) is a technique used to gather requirements and develop software, as an alternative to more traditional text-based techniques.