PM Around the World

I spent about half my career as a product manager in the US, my home country. In 2007, I moved to Germany and have lived here (happily) ever since. My perception that our discipline is a bit less mature on this side of the pond was to no small extent shaped by the fact that I came to help establish product management at a large software company. Since then, I’ve had this nagging feeling that product management isn’t as well established in Europe as it is in my homeland, although one has little trouble finding PMs here. 6 weeks ago or so, I started this blog. The Blogger stats on the location of visitors would seem to confirm my suspicions, although my findings are far from scientific (I was a point or two away from flunking statistics in college).
 

I expected a large percentage of traffic from the States but was a bit surprised at the massive proportion. I also expected Israel to be disproportionately represented (I have some experience with Israeli software firms and sensed that product management is well developed there {I also read Mr. Steinhardt of Blackblot’s stuff regularly}). I can tell from comments and forum activity on LinkedIn that India has plenty of (very thoughtful) PMs.

Although I’m not completely surprised at the geographic distribution, I’m also not sure exactly how to interpret the massive preponderance of hits from North America. Does it mean that product management simply hasn’t caught on in much of the rest of the world? Is it because I blog in English and promote my blog on LinkedIn (also in English)? Does it mean there’s less software development going on in other countries? Once, while poking around for PM jobs in Brazil (where I’ve also lived and worked), a recruiter told me that there simply wasn’t sufficient software product development there to sustain much of a PM community. I hope it's obvious that I'm not trying to draw scientific conclusions from anecdotal data, just curious if it conforms to other people's assumption about PM mind share around the globe.

Pondering the meaning of the numbers reminded me of conversations I’ve had with European headhunters and others regarding American- vs. European-style PMs. The perception seems to be that American PMs are more empowered and assertive. Conversely, European PMs are expected to do product definition work with more constraints and guidance from above. I realize these are generalizations, but they don’t seem to be way off the mark based on my experience.

What do you think?

Project to Product: An Introduction

I’ve recently stumbled upon a few companies that are thinking seriously about or are in the process of making the transition from a software services/project-oriented business to a software product business. I must admit during most of my career this type of evolution was not on my radar at all. I was a consultant for several years in the 90s, but for a major software vendor (IBM/Lotus) building customer-specific solutions on top of an established software portfolio. I didn’t have much insight into more traditional consulting firms that develop client-specific software from the ground up as part of consulting projects. It turns out that transitioning from a services organization that delivers software assets as part of a project to a company that ships products can be far more challenging than it might first appear. This change also raises plenty of fascinating questions about all kinds of software development topics, including software product management.

As these consulting/services organizations rationalize software re-use over time, they sometimes reach the conclusion (for various motivations I’ll address later) that they would like to ship “proper” products rather than customer-specific software assets. Although transitioning from a services-based business model to shipping products can affect virtually every aspect of a development organization, I’ll first focus on product management in future posts after laying a little ground work. Truth is, this topic is so complex and rich, I could probably write for months on the topic.

One of the things I’ve noticed in each of the companies that I’ve observed is the immediate struggle with terminology and concepts when the idea of developing products is broached. You might assume most people who develop products could understand the idea of a software project readily. Software releases have historically been managed as projects after all. You might also assume that folks delivering custom software projects for specific customers “get” products. I mean they buy products of various types regularly, including software products, right? However, in each of the cases I’ve seen, it was painfully evident that this assumption is completely wrong. In particular I’ve seen significant difficulty with project-oriented professionals understanding what a product is and what the implications of product development are to a software development organization.

Let’s quickly take a step back and define a key term: product. Although there is no shortage of definitions of this term (just ask Google), in my mind, a piece of software classifies as a product when it is delivered in the exact same form to multiple customers and is managed throughout its life cycle at these customers. That means no customer-specific versions or forking the code for every new customer project. Every customer over time has essentially the same executables and calls the same support line if (let's face it, when) there's trouble.

It is also helpful to define the term “solution”. I consider a solution an aggregation of products, services and other solutions that solve a customer’s problems. Solutions are important because services-oriented companies typically don’t deliver a software product alone -- they sell products as part of broader solution that often includes a significant amount of consulting and customer development work.

So what might motivate and organization to deliver products? Here are the ones I'm most familiar with:

Profitability
After years slugging it out in competitive situations for each project and developing software that only a single customer can use, the idea of building something once and selling it to a number of customers that is often an order of magnitude greater than the current client base can sound very attractive. It seems attractive on the revenue and cost sides (developing one thing instead of many things at least seems cheaper). In a future post, I’ll articulate the key differences between a services-oriented approach and shipping products, including the revenue model.

Valuation
Some companies would like to go public or get acquired. Typically, a company selling products is valued much higher than a services company as the latter has a built-in constraint on revenue: the number of person hours available to bill (these firms, of course have other ways to generate revenue, but the number of billable hours for a given workforce and "cost plus" pricing are clearly constraints). My cursory research shows that, ceteris parabis, a product company is valued at a much higher multiple (of revenue) than a services company.

Support Cost and Complexity
Once custom solutions have been delivered to multiple customers, often with slightly different versions of the same code base, organizations realize that the cost of supporting all these versions and managing the concomitant development complexity is unbearable. The notion of having a single software product that evolves and is managed holistically can be irresistible to these firms.

Customer Perception
Some firms feel pressure to move to the product paradigm because their customers want the perceived security of buying a product rather than what they perceive as a bespoke solution cobbled together during a project. Products have track records and other customers that can share knowledge and experience. The upshot is, organizations with products are often perceived as being more mature and thus more reliable.

In my next post on this topic, I'll discuss the perennial challenges or hurdles I see these organizations facing as they attempt to make a profound change to their organization, its process and roles.

Do you know of organizations considering making this change or already engaged in it? What was their motivation?

What I look for in an SPM candidate

I recently wrote a post giving some tips on making the transition to software product management (SPM), particularly for people already involved in software product development. The resulting discussion got me thinking about what I’ve looked for in SPM candidates over the years. I’ve done at least my fair share of interviewing during my career for teams I was managing, teams I was on and other products’ teams as well. Below, I’ve tried to identify the characteristics I consider most important for an SPM candidate beyond basic professionalism and SPM experience. Although many organizations have guidelines for interviewing and hiring, assessing candidates clearly has a significant subjective element, so you should take this post for what it is: one person’s (educated) opinion about what separates a great candidate from the good, the bad and the ugly.

Smart > intelligent
This is clearly a matter of semantics, so I would first differentiate between people that are really intelligent (have high IQs, for example) and those who are smart, which to me means the ability to combine abstract knowledge, practical experience, common sense and guts to find the optimal solution quickly. Being an SPM means continually making critical decisions without having all the information or time you need. Gaps in the facts must be filled with a combination of judgment and intuition while the clock is relentlessly ticking. Smart people know when they don’t have enough information to make a decision and when they have just enough input to deliver an important decision in a time frame that’s relevant. Very intelligent people that aren’t also smart can overlook the importance of timeliness and wait too long to collect what they consider a complete factual basis for a decision. People that are intelligent and not smart can alienate others (sometimes inadvertently) by continually trying to prove how clever they are. Smart people understand that they don’t need to be the smartest person in the room to facilitate efficient interaction and get the job done.

I’ve interviewed and worked at multiple companies that think it’s clever to ask a few questions that test candidates’ raw intellectual horsepower. It was part of their culture. While I understand their intent, I’m not convinced a Mensa membership or the ability to calculate the probability of a particular poker hand will make you a great SPM. I guess these types of questions could be used to differentiate the top few candidates, but I always found the practice a bit misguided and sometime even inappropriate, particularly for senior positions.

In my experience, a great way to get smart about products is to spend time in the field delivering solutions under tight constraints. Consulting can be a great way to develop product smarts (I elaborate on this point below).

Experience over education
I’m a big fan of higher education, but I would much rather have someone who has proven themselves as a product manager, even in a limited capacity, than someone who has an Ivy League MBA but hasn’t spent months in the emotional grinder that software releases can be, maintaining their sanity and passion for the job. This criterion may not be encouraging to those without SPM experience, but the truth is all of us want to know an experienced contractor is at the helm before they tear up our bathroom for a remodel, regardless of their training pedigree or certifications. The same applies to a critical SPM job. A bit more latitude can obviously be given if the position in question is a bit more junior, e.g., owning a set of features rather than the whole product.

Resist rushing to a solution
I usually give at least one design problem to a candidate in an effort to assess how systematically and efficiently they approach the solution. One of my favorite scenarios is asking them to design an elevator system for a building with 10,000 floors. Technicians like developers and architects sometimes get carried away with a creative technical solution without doing the critical ground work required to identify the requirements and constraints that must be considered to identify the optimal solution. If a candidate doesn’t start with identifying key assumptions such as the nature of the building, e.g., commercial vs. residential, little else they say is likely to impress me. I look for candidates who dedicate at least the first 20% or so of their response to asking me questions. I then expect them to quickly identify all the key stakeholders. In the elevator problem for example, I expect them to identify the economic buyer of the elevator system and what their key motivators are. Inexperienced people will consider only the needs of the riders of the elevators, overlooking the fact that the people paying for the solution need to conserve physical space (which ostensibly impacts the profitability of a commercial building) and tightly manage costs.

Software life cycle knowledge
I’ve recently been involved in discussions on product management with folks outside of software. While many of the basic principles of product management are not dependent on the product domain/industry, an SPM needs to understand what it takes to develop software, the stages of development, the strengths and weaknesses of various development methodologies and other software basics. SPMs almost always have to lead by referent power (as opposed to explicit power), so the inability to relate to developers, understanding their agenda and pain, can be a lethal deficit. I think a superstar from non-software PM or a candidate for a relatively junior position could be hired on potential, but I still consider it a significant risk.

I once interacted extensively for a period of time with a member of a team that defined methodologies for a huge software company. I was so impressed with his business insight and enjoyed working with him so much that I broached the topic of his working on my team as a PM. As we began talking about the the SPM team's relationship with the development organization, he bluntly asserted “I have no idea what developers do all day.” It was huge surprise to me and a deal-breaker in terms of any meaningful role on the team. I’ve seen SPMs that were such effective leaders or were so respected for their business or field knowledge that an understanding of the intricacies of software development wasn’t critical, but they are very clearly the exception (a single-digit number of people).

Self-assuredness bordering on arrogance
The most effective SPMs I’ve worked with had an air of self-assuredness that initially could be mistaken as arrogance. Let’s face it, getting a diverse set of stakeholders to buy into your vision and be convinced that you can actually deliver on it takes some chutzpah. I would also say that there’s a very fine line between strongly believing in yourself and being arrogant. Candidates that sing their own praises without acknowledging the contribution of others or don’t have a track record of successes to back up their attitude don’t get to far in interviews with me.

Ability to be self-critical
This may be a general criterion that I find important for any job candidate, but given the hubris one finds in many SPMs, being genuinely self-critical is particularly important for people pursuing this role. Being self-critical may seem on the surface contradictory to the idea of someone being self-assured (see previous point), but it is the “other hand clapping” that keeps successful SPMs grounded. I typically ask candidates what their biggest professional failure was milliseconds after enabling my highly tuned bullsh*t detector. I’m not looking for clever interview responses with transparent attempts to couch a strength as some sort of weakness, à la “Sometime I pay too much attention to detail” or “I sometimes work too hard”. I look for a bit of discomfort as they tell me about an instance in which they tried something ambitious and clearly failed. In general, the bigger the failure they’re willing to share, the more points they score with me. I of course probe further to convince myself that they learned from their failures and that failure is the exception in their career rather than the rule. It has become clear to me over the years that if you don’t have painful stories of failure, you either haven’t been tested in a sufficiently challenging environment or you have held back, avoiding the truly risky work that separates those who are attracted to the “bleeding edge” from those that are skilled at staking a safe, career-building course. As a job candidate, formulating a response that is sufficiently forthcoming without alarming the interviewer excessively is dicey. This is exactly what makes probing this characteristic so enlightening and valuable.

Consulting experience
I mentioned the importance of consulting experience in my original post but didn’t elaborate much. A few years in software consulting will almost inevitably take you through the entire development process multiple times in an environment in which effectively managing budget and scheduling constraints means the difference between a profitable engagement and a financial sinkhole that can damage the client, the reputation of the consulting organization and the engagement team. When college grads ask me what they can do to become a product manager, I invariably suggest they seek a challenging role in consulting first.

Heart
I realize this is an imprecise term, but I ALWAYS look for someone who has what I can only characterize as “heart”. People with heart will push themselves and the rest of the team to their limits not because they want to advance their career or because they seek personal glory, but because they have pride in what they do and desperately want to help the team win. People with heart have often overcome significant adversity in their personal and professional lives to get where they are and will keep swinging long after others have given up.

I once had to fill a position from a pool of internal candidates that was less than ideal. One of the rather meek members of the development team applied, generating all kinds of water cooler discussion and plenty of dismissive statements made directly to me. Although she didn’t have a track record as a leader and clearly didn’t have the full respect of her co-workers, I hired her because it was clear to me that she had battled those same perceptions throughout her life and had managed to keep her head above water, even in a very challenging professional environment (that shop was a real pressure cooker!). With a little conspicuous support and one-on-one coaching, she surprised everybody by growing into an effective and decisive SPM that was respected by the team and leadership. It was a pleasure to work with someone who was humble yet ambitious and was willing to bite off more than she could chew at times to make things happen. Remembering her inspires me to this day

Summary

I realize this post may alienate some people and that other folks have different priorities. Regardless, I hope sharing my personal priorities or even biases will encourage others to share what they find important in SPM candidates. I take hiring very seriously, considering it a critical process in any organization and one that surprisingly rarely gets the thought and attention it deserves. For every Microsoft or Google that has a highly effective and even grueling hiring process, there are thousands of other organizations that leave candidate selection to the subjective whims of a few people that conduct superficial and ineffective interviews. I'll post more on interviewing later.

Now that you know how I feel, what characteristics beyond basic professionalism do you look for in SPM candidates?

Product Management vs. Product Ownership: Who's on top?

First things first: Sorry for the provocative title. I used the potentially antagonistic "vs." because, although there seems to be massive overlap between most definitions of product management and product ownership, I sense a bit of something approximating rivalry in discussions of how they relate to each other. Perhaps it’s a product (no pun intended) of “old school” thinking vs. the relatively new Agile mindset. I say “relatively new” because product management in one form or another has been around since the 1930s, although obviously not in the realm of software. Regardless, the central question in some quarters seems to be “Is product management a subset of product ownership or is it the other way around?”.

For what it’s worth, I’m not convinced there’s a right answer to the question or that the answer, if one exists, really matters much in practice. To my way of thinking, there are certain functional accountabilities and proficiencies that must be covered for optimal, long-term product development and each organization can call it whatever they want. I’ve defined a simple model that describes SPM (or PO?) proficiency holistically along three dimensions: business leadership, product definition and product promotion. In my experience over the last 10 years or so, I’ve seen a tendency emerge that I thought might be interesting to share. Truth be told, this experience has led me form an opinion on the topic, but just barely. That makes this post nothing more than an elaboration on my two cents and an attempt to give those confused by the relationship of these terms some food for thought. For the record, I’ve been involved in the introduction of product management and the transition to Scrum on multiple occasions and I am a huge fan of Agile/Scrum and, by the way, Lean.

When I first started thinking about the distinctions between the two, I though maybe I should consider PM as a job title and product ownership as a role. However, if you do a quick search on job sites, you’ll see that the lines have been blurred into oblivion. The product owner job descriptions I read come right out of the Scrum play book but are posted as open positions with corresponding titles, just like PM positions.

Since product ownership is defined as part of Scrum, I find the key differentiator of this role is the close collaboration with a Scrum team (what we called “teams of ten”) based on the backlog and Scrum ceremonies. Much of the other responsibilities such as being ultimately accountable for the success of the product, defining the product vision etc. seem essentially identical between the two based on what I've read. 

I’m not sure if it’s due to the relative immaturity of some of the organizations I’ve been involved with, but my experience has shown that providing the team with what they need as a product owner, including participating in Scrum ceremonies, can be more than full time work. That left us with the situation in which a product manager was accountable for the product overall and retained that (or a similar) title, with multiple product owners reporting in a dotted line to them (in these cases, product owners continued formally reporting to development). In this arrangement, PMs spent most of their time on relatively strategic activities like defining the vision, managing stakeholder engagement (involving the POs of course!), defining release goals and managing requirements, but at a fairly high level of abstraction. POs spent most of their time decomposing requirements into consumable user stories in the product backlog and participating in Scrum ceremonies. They clearly collaborated heavily with the PM on strategic activities but weren't accountable for them.

So, in my mental model and my experience, product ownership is a subset of product management. More specififically, I see product ownership being focused on the Product Definition dimension in the competency model I mentioned earlier. SPMs would therefore tend to focus a bit more on the other two dimensions, Business Leadership and Product Promotion (although clearly continue to play a critical role in product definition, but at a higher level of abstraction). Regardless of the division of labor, tight collaboration between product managers and product owners is essential. I tend to consider PM a job title or an organizational position and product ownership (regardless of how related jobs are posted on Monster) as a role defined by the Scrum framework. In orgs that must create a hierarchy for functional product development accountabilities, the PM's center of professional gravity is around the more strategic aspects of the product while POs focus on the tactical work of giving the development team what they need to build the software and accepting their work. Does this distinction provide important organizational or operational guidance? I'm not sure. I'll be happy if my opinion generates some insight-producing discussion. For the record, the literature I’ve read on scaling Scrum and my experience shows that typically, the “product owner” moniker (or a close derivative) is retained at each level of the hierarchy.

A practical issue I find with considering product management a subset of product ownership is that it’s not clear to me that it makes sense to use Scrum-based terminology in organizations that haven't adopted it. Believe it or not, plenty of critical software is still developed by teams that don't use a backlog or develop in sprints. (I recently saw a survey indicating that the most popular development methodology is no development methodology at all!) Product management is also deeply entrenched outside of the software domain and I don't see Agile storming development of these other types of product as quickly as it did software. 

Another potential problem I see with claiming product ownership defines the superset is that Scrum claims to be not a methodology but a framework. In my interpretation of the term “framework” and based on what I’ve read in practice, frameworks define basic principals and leave much of the further detail to interpretation by the practitioner. I've read all kinds of additional commentary on what the product owner should/could do, but, to me, these are just opinions and guidance filling in the gaps in a framework. My question is: Can a framework ever define a detailed description of a role such that one can assess fully how it compares to what I consider more comprehensive, detailed definitions? I’ve seen very detailed descriptions for product management by organizations such as ISPMA. I’m also suspicious of attempts to rename something based on a “new” framework when I have trouble differentiating many of its basic tenets from the ideas or concepts that preceded it (clearly the overall approach to development is fundamentally different with Scrum, but as mentioned earlier, descriptions of the product owner role itself contain massive overlap with descriptions of traditional product management). Recasting traditional product management in its entirety as product ownership feels a bit like the proverbial old wine in a new bottle. Maybe it’s just me.

By the way, I previously mentioned organizations that “claim to have adopted” Scrum. Allow me to cite an obscure truism from one of my college business law professors: “Calling a cow a horse does not make it a horse” (or was it the other way around?). Some organizations that claim to be doing scrum don’t meet the bar in my opinion. More on this later.

How to become a software product manager

The paradox many job seekers face of not being able to get work because they don’t have experience seems particularly acute for those wishing to become a software product manager. Because it’s such a critical job, many employers are loath to allow candidates from other disciplines like engineering to learn “on the job”. I don’t know of any sure-fire tricks for landing your first PM gig, but would propose that the following can help those already working in the area of product development (in development or QA, for example):

Let your organization know that product management is something you’re interested in
Seems basic, but many people fail to communicate career aspirations that entail a significant departure from their current job, fearing their dedication to their current position will be questioned. While that may be true in some orgs, there are non-threatening ways to indicate what you want in the future while reiterating your commitment to your current role. I once joined a consulting company in the Southwest part of the US and told them in the interview that some day I wanted to live and work in Latin America. A few years later my manager assumed responsibility for “LATAM” and guess who ended up living and working in Rio? Letting folks know what you want sometimes pays off.

Get exposure to software consulting
I spent several years as a consultant and feel it has played a huge role in my effectiveness as a product manager. As a consultant I had to engage with customers, understand their requirements and design a solution that delighted them and could be delivered on time and on budget. Repeating the process of identifying needs, designing a solution and developing it under tight constraints helped me develop reflexes that continue to help me do my job 15 years or so later. Becoming a consultant may not be possible or practical in your situation, but attempting to get exposure to consulting projects delivered by your company or partners might be feasible. Let management know you want more exposure to customers and attempt to build relationships with people in professional services.

Liaise with and learn from SPMs
If you’re in a role that requires collaboration with SPMs, e.g., development, marketing, support, invest in relationship-building with a product manager or product owner and observe how they go about their job. Note the things they do that you find effective and the things you don't; they'll be instructive once you make the leap. See if you can establish yourself as a key point of communication between product management and your organization. You can learn a lot and might get yourself on their radar for future PM vacancies.

Get trained!
There are multiple courses available on product management. Take one, even if it takes some clever justification like saying you want to understand the role better so you can collaborate more effectively. Product managers are involved in a broad range of activities so a solid conceptual foundation can help you identify areas in which you need to grow. Some organizations also offer certification, which might demonstrate to potential employers how serious you are about the PM discipline. I’m a member of ISPMA and find their syllabus comprehensive (I also provide training based on it) and like their approach to certification (done by a third party). There is no shortage of other organizations that provide similar learning opportunities so do your research and pick one that suits you.

SPM one of your own ideas
We live in the era of start ups. If you want to become an SPM, learn about the discipline and apply your knowledge to a business idea you dream up. Even if your idea doesn’t make it to market as a viable product, you will get insight into the challenges of taking what intuitively seems like a good idea and demonstrating that it could be a successful product and then developing it. Taking on the role of a product manager or product owner for a group of developers (even if you’re one of them) will give you invaluable experience and knowledge you can’t get from books (or blogs!).

Immerse yourself in SPM knowledge and theory
There is a massive amount of free information available on the Web about virtually all aspects of product management. Start reading blogs, Web sites and news articles on SPM. Buy books, watch online videos and participate in related forums.

So those are my recommendations for increasing your chances of becoming an SPM. Looking forward to hearing suggestions from others and hopefully feedback some day that these this post actually helped somebody make the change.

You can find more information on me (including upcoming training dates) at www.prickril.com.

Innovating in Big Shops: The Puppy Parable

Innovation gets tons of press and blog real estate these days, much of it associated with internet startups. I have more experience innovating (or at least trying to) at some of the true behemoths of the software industry, which I assume provide a much different experience than what I imagine happening in the fabled garages in the Valley. The idea that “big shops” have trouble innovating is fairly well established although probably a bit overstated. The story arc of innovations at these companies is probably less well known. After what is likely too many years on these big ships, I’ve noticed a fairly consistent pattern of behavior when it comes to innovation (or even just new thinking). Please allow me to present a little parable describing the typical “Stages of Innovation” at a mega-corporation.

Stage 1: Your puppy is soooo cute!
In this stage, folks in management and those working on more established products hear about the idea you’re incubating and, if it’s compelling, treat it like a precious puppy you just brought home from the pound. Their enthusiasm for your cute little bundle of slobbering joy is mostly genuine. They are happy to see the organization thinking out of the box and will likely pet your puppy enthusiastically, especially if they see folks in upper management rubbing its belly and cooing with delight.

Stage 2: That puppy is starting to annoy me!
In this next phase, your puppy is becoming more and more energetic and has begun yelping at inopportune times, drawing attention away from the other dogs in the kennel, i.e., other products in the portfolio or ideas in the pipeline. In its youthful exuberance, your puppy may have even left a couple of unexpected “surprises” here and there, disrupting a kennel that had been relatively orderly and predictable.

Some folks will now start distancing themselves from your puppy, becoming irritated by its unbridled energy and sporadic clumsiness. Their diminished affection is symptomatic of an increasing sense of angst: Your puppy is growing up and may become a threat to the other dogs in the kennel. In an ironic twist, the owners of these other dogs often begin frantically relieving themselves on almost anything in the vicinity (like development budget), marking their territory and relieving their mounting stress.

You will begin to sense other’s unease but will write it off as someone’s having a bad day or at worst mild case of envy. After all, who could possibly resist the cutest little puppy anyone’s ever seen (in your eyes, anyway).

Stage 3: That puppy MUST DIE!
In this stage, no one remembers their initial fondness for your puppy. It’s getting surprisingly strong now and its sharp little teeth are causing unbearable pain to the tender fingers and toes of the other dog owners. In the blink of an eye, the gloves come off and people start casting aspersions at your little puppy, sometimes to your face but more often behind closed doors. They say it’s out of control. They say people on the outside will never like this vicious little ankle biter. In extreme cases, they’ll claim he’s rabid. The more diplomatic among the dog owners, paragons of consideration that they are, will start suggesting humane ways to quickly euthanize your puppy. Others will show up on management’s door step with a burlap sack and a pile of rocks.

As the puppy’s devoted owner, you will be perplexed at these developments, astonished that there are people who don’t LOVE your puppy as much as you do. Your parental instincts will kick in and, if you’re not careful, you will do irrational things that will put your puppy in further peril. Keeping your wits about you and not letting the bullies see you sweat are highly advisable at this stage.

In the next stage, we assume your puppy has survived the onslaught of slander, collusion and outright aggression that threatened it, developing into a healthy little scamp that is loved by all. Unfortunately, this is by no means the most common outcome but, let’s face it: No one likes to read (or write) about dead puppies.

Stage 4: Look at my dog!
In this stage, typically once you've shipped, you play the part of the proud owner/parent, basking in glory of the highest praise that can be bestowed up you and your little pet: People now claim him (or her) as theirs. Those who once harbored fantasies of running him over multiple times will now regale you and anyone else within earshot with tales of how they were the ones who had the idea that the kennel needed a new puppy in the first place. They’ll brag about how they helped pick it out from the litter and might even grow nostalgic remembering about all the nights they stayed awake helping you nurse it through its difficult early months. After all, what are friends for? Your new bestest buddies, self anointed aunts and uncles, will begin looking for conspicuous opportunities to laud your puppy in front of execs, demonstrating what selfless team players and understated visionaries they really are.

You will feel an overwhelming urge to give these proud new “owners” atomic wedgies. Being the professional you are, you will keep your composure, knowing you are a member of an elite club of people who managed to move the excitement needle on the dash of a mighty oil tanker that rarely sees any change in course or speed.