Desperation in the business world

I see things that strike me as acts of desperation.  Yes, the economy is bad, bad, bad.  For an indication of just how bad, you should really spend some time viewing The Crash Course at ChrisMartenson.com.  

However, I've noticed some things that are real strong indicators that marketing and product folks are getting desperate.  Here are two of them:

Trader Joe's.  I love Trader Joe's.  I get really good quality food at great prices.  For example, we try hard to eat organic when it comes to raw foods; milk, eggs, veggies, fruits, etc.  As an example of the great deals, TJ's sells a gallon of organic whole milk for around $5.98.  Shaws and Stop and Shop also sell gallons of organic whole milk, but for around $8 a gallon.   

TJ's used to sell a pound of organic romain lettuce in a bag of three heads.  It was a great deal and in the Summer, my wife and I would go through two of those bags a week.  However, a while ago -- could be a year, could be longer -- I noticed that the bags were lighter and were now being sold in 12 ounce packages.  Same price, but we were now getting 25% less.  That's a big increase. Last fall I noticed that some of the bags felt noticably lighter yet again.  That's because they now sell "Three heads of organic romain lettuce"  No weight indicated.  I promise you, some of these bags have three scrawny heads of lettuce in there that barely top 8 ounces.

Same bag, same big title, a tiny fraction of the value.  

Here's the second thing.  One of my credit card companies called me and I finally answered -- I hate being interrupted during family time.  Ms. Dublin politely identified herself and thanked me for being a long-standing member.  Then she asked my permission to read a paragraph and record the remainder of the conversation.  I initially assumed that she had to notify me of some change in the terms, but was puzzled why it had to be over the phone.  Since she was simply reading a paragraph, it didn't seem like she was trying to sell me something.  But there was that recording part.  Hmmm.

In the paragraph she said that they would be enrolling me in a program that would monitor my credit reports and notify me of any changes or threats and that after some introductory period, they would bill my account $9.99 a month.  It seemed that the company was trying to say that by listening to the paragraph I implicitly accepted the terms of this service that they were foisting on me.

I said that I wanted it clearly understood that I do not want any such service and that I am not agreeing to accepting any such program.  Ms. Dublin replied that I have the choice of opting in, but by accepting enrollment, she would simply send me the materials.

Really, what kind of malarky is this?  You want me to look at the materials?  Fine.  Send them to me.  However, you don't need me to agree, on tape, to have you send me the materials.  

So, I felt it necessary to state again that I was not accepting any enrollment in any such program and do not want any charges to be applied to my account for any such purpose.  Furthermore, it seemed that by accepting enrollment in order to get the materials, the company was equating that enrollment with accepting the automated billing of this service and I wanted it clearly understood that I was not accepting any such service levied to my account.  

I'm glad they were recording that.  :-)  Ms. Dublin thanked me and hug up.

The lesson here is that both of these programs are tricky and underhanded.  I love Trader Joe's a good deal less now and I do not trust this credit card company at all.  

Is that really the way we want our customers to think of us, our products and services and companies?  Nope.  It's baaad policy.  Baaad products and baaad practices.  

Don't surprise the customer!

I recently purchased a replacement toner cartridge for my laser printer.  I really, really wanted an OEM cartridge.  My experience with compatible ink jet cartridges were unsatisfactory and even though OEM was significantly more expensive, I believe that's the way to go for the best quality results.  Since I use my laser printer for business correspondence, it is important to have crisp, clear copies.  

Furthermore, as a toner cartridge for a SOHO printer ages, the light sensitive imaging tube becomes less sensitive and the copies start to come out grey.  So, simply refilling the toner powder won't do either.

However, I was horrified to see the prices for the OEM cartridge.  Nothing less than $75, some over $85, and then there's shipping! Yowza!  $120 for a cartridge -- I could practically purchase a new printer for that!  I seriously thought about it, but knowing that my wife would kill me for such blantant consumerism, I went back to looking for a replacement cartridge.

I Googled, and Googled.  Seriously searched for an OEM cartridge that would be less.  I would have been happy with $60 shipped.  I was delighted to find a site that was selling a cartridge for $32 shipped.  That's was the same price as the compatible and refurbished cartridges.  I check and double checked to make sure that this was an OEM cartridge.

The product ID was the same as the OEM ID -- "ML 1210D3".  Check

The product description was the same as the OEM -- "Samsung ML-1210 D3".  Check

The description did not say "compatible", "refurbished", "refilled" or any such thing.  No where did it use those words on the product page.  I even searched for them. Big Check.

I placed my order satisified that I had finally done it!  I found a site that was selling OEM cartridges for deep discounts.  I was ready to trumpet the value of this place.

However, when the product came, it was clearly a knock off.  I called and emailed the company.  I pulled my receipt.   Yep, "Samsung ML-1210 D3"  I was not expecting a knock off.

I got a response in less than 24 hours.  Here is the first line:  "If you would have read our paragraph about what we do on our homepage you would have read we provide toner replacements for expensive name brands(OEM)"

I never saw the home page.  I came to the product page from a Google product search.  I never saw -- and I looked for -- something that said I was purchasing a knock off brand.  In my mind, this is a complete failure on behalf of the company.  It's folly to assume that your customers are (1) going to enter your site on the home page and (2) read it if they do.  

This isn't right.  I will not ever do business with this company again for any reason whatsoever. There isn't any need to.  They have so much competition and their products and their service is an absolute commodity.  Plus, they surprised me and then blamed me for it.  By the way, I did look at the home page.  It does say that.  Right in the middle of a paragraph of text that I never would ever have ever read ever.

Here's the take away lesson:  Don't do this!  Do not suprise your customers unless it makes them very, very happy!

If you are in the product industry, you must make sure that your customer knows what they are getting and are satisified with the value of the product.  If you are in the service industry, you must ensure that your customer knows what they are getting and are satisfied with the value of the service.  Unpleasantly surprising the customer is the very best way to kill your up sale potential.  

But, Peter, you say, I can't spend all day hand-holding every customer.  Sure, OK, I'm good with that.  However, you can -- and you must -- ensure that your customer knows what they are getting.  Period.  Your promotional material, your descriptions, your literature needs to be complete and honest.  Because you can't afford to acquire a new customer for every single sale.

You might be interested in which company it was.  I was initially going to reveal that, but I decided not to make this a "bash the company" posting because I really want the lesson of good customer relationships to come out.  So, I'm not going to say.

A great demo movie

Boy, I wish I had an active project RIGHT NOW. Because I just watched the FogBugz demo at FogCreek.com. This was the most enjoyable and informative demo movie that I have ever seen. Bar none.

The CEO, Joel Spolsky, and one of the programmers, Babak Ghahremanpour, talk casually about FogBugz, which is a hosted or in-house project management system. Their dialog, which is friendly (except for when they rip into poor Milton Richie), informative and interesting, told me everything that I could want to know about FogBugz's functionality.

I am so excited about this that I have even done my normal due diligence of looking for reviews and independent assessments. I'm ready to start my free trial, just because I can!

Hmm, maybe they need a really great product manager. Gotta go.

What is the biggest problem you have with your camcorder?

I've been wondering about this. For me, I have tapes that I can't see,
stuff I can't find and dozens of tapes to manage. I love having the
record, but what good is it if the media will decay and I can't see my
movies?

Please share your thoughts on the matter. I've made a poll on LinkedIn
with their new poll feature. Please come and vote at
http://polls.linkedin.com/p/20725/ejgif

Thanks!

Mysteries of On-Time & On-Budget revealed

Yes, true believers, now is the time of your enlightenment. For years have you stumbled in the dark, arms raised, hands reaching, gingerly feeling for obstacles. You have relied upon truisms and common sense to get you to your goal, knowing that if you only stay on the straight and narrow, you would succeed.

I, too, once believed the same. I, too, used to tout that the way to success was a straight and narrow path, fraught with danger and risk. "DO NOT STRAY FROM THE PATH!" I used to preach, "for the number of roads to ruin are immeasurable, but that way to enlightenment is straight."

Horse hooey and poppycock.

Now hear this: You can build successful products on-time and on-budget over and over again. Here is the secret: constraint. Yes, if you have the discipline to constrain yourself, then you will experience the joy of on-time, on-budget.

The way it used to be

Here is what we all used to do. Tell me if this doesn't sound familiar.

Identify functionality (often in a room full of executive and managers). Document and define functionality. Design application -- user interface, object model, database schema. Finely define functionality for each component, estimate the work involved, identify risks and opportunities, weight the estimates with the risk category and produce a schedule. Assign costs to the schedule and develop a budget. Add padding. Review the preliminary specification (which hardly anyone would read), the preliminary schedule (which would invariably be pulled in for "business reasons"), the preliminary budget (which would be reduced). Revise, regurgitate. Stamp with seal of approval.

Begin work. If you were good, you would track progress against estimates. Within the first 25% of the project you were either on time, or you were slipping. If you were good, you would fix the causes that were making things slip, but for most of the projects, most of the time, you simply raised the flag "We are slipping." No one paid any attention until the last 25% of the project, desperately trying to fix something in the last 10%. Herculean efforts, late nights, long weeks, weekends, etc. You finished.

Congratulations, you had 85% of the functionality, were 20% over budget and 15% over deadline. Or something not too far from that.

You had a party, celebrated the success and kicked off the next project the next morning. After all, you had sufficient headroom and padding to ensure that even with this scheduling and budgeting failure, the product worked.

In reality, the majority of efforts did not produce a successfully released product. This is still true today.

The way it will be

Here is how you will change your life and be successful in producing remarkable products.

You will talk to your customers. Even if you are creating a brand new product for a new market that doesn't even exist yet, you will be selling it to someone. Find them. Talk to them. Call them. Ask leading questions. Listen. Ask and listen again and again.

This process will still produce a list of functionality. However, because you have gotten the pulse of real consumers who would pay real money for your product, you will know what is important to them.

Put the most important functionality at the top of prioritized list. Now figure out what is the least amount of work that it will take to produce the most important functionality. You are permitted to deliver only the top most item if necessary.

Now you may go ahead with your process. Design the user interface, object models and database schema. Break down each component and make work estimates, identify and assess risks and produce a weighted work effort. Apply costs to the work effort estimates to create a budget. Do not pad. Your weighted work effort already includes risk factors.

This is where you stop and take a breath. If the costs of producing only the most important functionality are greater than the market opportunity, then there is no justification for producing the product and you are done. Shelf the idea and go onto the next thing. You just saved yourself a huge bundle of effort and money.

However, if the cost/benefit equation is positive, then you know exactly what it will take to make a product with one tightly focused set of compelling functionality. Now it is time to begin your race.

Your purpose is to produce the most important piece of functionality first. Make it work to the exclusion of all else. You are in a race against time and dollars. Every day, whether you are using Gantt charts or Backlogs, you must make this assessment "Are we doing the right work to produce the most important functionality?"

Here is where you ability to constrain yourself and your team pays off. New feature requests? Put them in the parking lot. Changed functionality requests? Parking lot too. Your ability to focus your team to constrain their work will bring you success.

Plus, you will have noticed that you have a much, much shorter time line then you used to produce. The old way had you implementing all the identified functionality. Now you are implementing on the most important functionality. In my experience, my time lines went from six months to three weeks on average with this approach. Assuming only 4 weeks per month (it's really about 4.3 weeks per month), then I can do eight iterative cycles in the same six month period. EIGHT! That is a lot of opportunity for addition and improvement.

By the way, your team includes the executive staff, management staff, and line staff. It includes Marketing, Sales, Operations, Engineering, and Customer Support. After all, your company is the vessel and if there is a hole in the bow, the stern goes down too, so everyone is responsible for keeping things ship-shape. Keeping your entire team focused on accepting the constraints will keep everyone happy with the end results.

Here is the final key. You will STOP and deliver when the FIRST of these three things occurs:

1) You have completed the functionality you intended. OR
2) You have hit the milestone you identified. OR
3) You have spent the budget you identified.


"But, but, but" I hear you sputter, "But what if I hit the milestone and the work isn't done?"

How could that be? Didn't you identify the least amount that needed to be done? Was it really the absolute least amount? Didn't you design the components to fulfill only the least amount of functionality? Didn't you estimate the work and weight those estimates? Didn't you stay focused on delivering only the functionality identified? Didn't you resist the requests, demands and temptations of adding or changing functionality?

If you really did those things, then you really will hit one of those targets successfully.

What happens too often is that the design accounts for future expansion. Or the UI adds additional features that add complexity but are not required implement the most important functionality. Or the database incorporates infrastructure for expansion, growth, additional reporting. In summary, you failed to constrain the work to the most important tasks.

It is very easy to fall into those traps. Which is why company after company, product after product, program, project, etc. make these mistakes over and over. If you can avoid these mistakes, then you can lead your company into iterative, focused product development and enhancements that will keep your efforts prioritized by value to the company. Plus you will deliver on time and on budget.

Three really good product management blog postings

While researching various aspects of the health care industry, I came across this very excellent blog post by George Van Antwerp and decided to post it along with some others that I've enjoyed reading.

First, Mr. Van Antwerp's Lessons Learned. This is a delightful essay with which I found myself nodding enthusiastically throughout.

Next, his sub-post on Product Management 101. One take-away is to always have your elevator pitch ready.

Finally, I'd like to shout out to Sem-Answers on his Niche Market Research posting. I like the list of research resources provided here. (Also, by putting the link here, I'm confident I'll be able to find it in the future :-)

This is the way to blog!

I was reading some of the product management blogs I like -- the ones that aren't so darn dry that you can fart in your sleep and immolate yourself. Aaaand, I came across this beauty of a blog: The Cranky PM.

She is irreverent, on-the-mark, and funny, funny, funny.

Whoo! Damn that's good stuff.

Re-examining Assumptions

Last Friday I met with someone who surprised me in a way I've not been surprised in a long time. This experience has sat with me since then and is inspiring me to re-examine my assumption model.

You see, the meeting was a first conversation about a position in a company and, truth be told, I was very unsure about the prospects and viability of the company. It has been in existence for over a decade, has a good size staff, but, although a web company, did not have significant traffic and, although established, had significantly lower revenue (and higher percentage overhead) than I had expected and with which I am comfortable. In short, there were warning flags.

My assumptions were that the company was not fully executing on its potential, or that perhaps the competition caught up to it and surpassed it. So that is where I focused my pre-conversation research.

The person with whom I met on Friday impressed me. First, he wasted no time in spelling out that he expected significant growth and he laid out the core thinking to his expectations. He made sense and had a fresh perspective on the problem, which is that the company's traditional domain is no longer its current domain, or more accurately, its current growth opportunity domain. The company has to move from one focus -- let's say "newsletters and messaging for the on-line widget industry" is what the company believes is its current domain -- to a new focus -- let's call that "automated marketplace for connecting widget manufacturers to widget consumers" as its new domain. This person's thinking is revolutionary for the company.

Unfortunately for my "pre-screening interview", it was also revolutionary for me. I assumed that we would be talking about one thing -- the company's market position, brand, existing product line, and immediate growth strategy -- so I didn't scour the information I had sufficiently to anticipate where the conversation would go.

From my project and program management experience, I know that it is critical to identify and document the personal and project assumptions for efforts. One of my favorite books on risk management, "Risk Management, Tricks of the Trade for Project Managers" by Rita Mulcahy is a canon that embodies the assumption identification in the processes. I've used assumption identification to pull out critical risk factors in my product management work; it's been a huge differentiator that has helped me get past personalities and focus on functionality, opportunity and risks in new product development.

So I am more than chagrined that I slipped on this. That made me wonder if assumption examination is part of the professional zeitgeist. It doesn't seem to be. Looking around for conversations on how assumptions are recognized and incorporated into various processes, I found an article from EE Times Asia on Re-examing Assumptions, plenty on assumptions at the software engineering level, a little blurb on program risk management from PgMP by Paul Sanghera in Google Book Search, a news article on SEI from 2003. Much more on the engineering side than the business process side, in my opinion, although New Product Forecasting by Kenneth B. Kahn has a section on assumption management that caught my eye.

There is opportunity here. Seemingly there is need for some assumption evangelism -- how are you going to check into your working assumptions about the important things in your life? I know what I'm going do about it in mine.

Software Development Process and the Start Up

Start ups are great places, if you like that sort of thing (and I do). Small groups of individuals infused with the entrepreneurial spirit working intensely on their Next Big Idea is invigorating. Strong, smart people can make a huge difference, albeit sometimes with herculean efforts, but at some point (more on this later), you launch.

Then you go right back into it the next day.

Which will eventually burn you out.

But greed and excitement are wonderful things, so you muster your energy, take a deep breath and dive back in. The launches are satisfying. The acknowledgment from your peers and management are satisfying. The accolades, press releases, funding efforts, and the promise that you are contributing to the Next Big Idea are all satisfying. But you know that it can't continue forever; that at some point the company will need to cross over from Commando stage to Infantryman stage and then eventually to Policeman stage (use what ever stage names you prefer here).

So here's the question; What do you need in terms of process at each stage?

Let's work our way backwards. No one would be surprised to find a mature CMMI and ITIL led organization at the Policeman stage. Some degree of CMMI maturity would quite natural for a company at the Infantryman stage, say CMMI maturity level 2 or 3; repeatable and documented process, improvement processes and some feed back capability.

But what about Commando? What about start ups? Eventually the commandos will move on and the company will be taken over by Infantrymen, but that could take years. For how long will the Commandos be running on their own gumption?

Those who live by process know the value it brings; reduced flailing, more reliable delivery, lower defect rates, greater alignment to business objectives. However, there is the challenge of perception to overcome. Perception that process interferes with creativity, introduces bureaucracy, hinders agility and is too expensive. Especially within the start up environment, which is often Cowboy development. "We have smart people, we don't need all that process stuff"

Poppycock and balderdash.

This is a simple case of "enough." Just enough process to deliver effective products. Just enough framework so that everyone knows that stages. Just enough practices so that a repeatably effective cycle can be created. Just enough monitoring and feedback to that mistakes are not endlessly repeated. Just enough borders to ensure that goals are repeatedly redefined to the point of ineffective thrashing. The basic check list is short:

• Short, but effective cycles -- this allows for flexibility and redirection without throwing away effort.
  
• Clear deliverable at the end -- the thrill of victory is a strong motivator
• Clear success factors -- New features in this build? Then only new features. Bug fixes? Then only bug fixes. One new feature and three critical bugs? Fine; do only that. What is the least amount that you can do to be successful in solving todays problems.
• Blessing and direction from senior management -- no sponsor, no work. The stakeholders decide what is the most important thing for them to have.
  

It is quite possible to respond to the short-cycle real-time demands of a start up. After all, the start up is first an idea. That idea will be tested by your customers, who will then tell you what business you're in.

All that stated, you have product to deliver. There is time pressure, and although there are unending pressures to constantly change, tweak and improve your product, you simply HAVE to launch. You HAVE to get to a launch date and the product MUST be released. Never loose sight of that.

So then the next question is "How can you manage the exchange of endless pressure with the real-time need to deliver?"

This is the job of product management. Product management starts with industry and market knowledge, time to market and market opportunity, cost to develop and return on investment. The funnel of endless ideas must be quickly and efficiently evaluated by a capable product manager. The value of the idea needs to be quantified without romanticism. The cherry picking becomes much easier at this point.

In summary, enough software process in the start up will produce superior products more effectively than ad hoc or heavy handed models. Focusing the development work on valuable efforts comes for successfully vetting the opportunities and defining the critical success factors.