Tag Archives: Uncertainty in Software

The Top 5 Rookie Mistakes in Software – #5

Lack of Focus

(read the intro first if you haven’t already)

Call it hubris, call it ego.  Call it a lack of understanding of the market and user, but a huge rookie mistake is to try to do too much.  How many times have you heard this bit of common-sense wisdom, “It doesn’t have to do a lot, just build it to do a few key things and do those things well.”?  It makes sense right?

It’s unfortunately easy to lose sight of this little rule-of-thumb when the momentum of product roadmap overtakes you.  You browse around a competitor’s website, for example, and discover that they’ve just released a new version that has a new feature X; but you have no plans to build feature X in your tool.  Well, now you need to add feature X to your scope to remain competitive.  Or, maybe your legacy product has feature Y and your existing customers have learned to depend on feature Y to do their business.  How can you ship your new product without feature Y? Add that to the scope.

Add a hundred more components and modules and exports and reports that keep getting added and added through demands from a few sales & marketing people, some customers, your favorite SME’s and a BA.  Your simple, focused product has now ballooned into a Colossus that will take 800 man-years to release.

So, am I talking about Scope Creep?

Not at all.  Scope Creep is one of those old, pre-Agile sayings that poorly organized dev shops used as an excuse not to ship software.

Scope will always change and creep.  It’s normal, healthy and all a part of building an effective product roadmap.  To maximize the competitive opportunity of your software, you need to be open to new market information, business drivers and innovative ideas.  These will always change and add to your product backlog (total scope).  Change, scope creep, uncertainty, etc. is all GOOD, wholesome stuff in the world of software and technology. Our learning path evolves every minute of the day.  Think of it this way: if you don’t know more in 6 months than you do right now, you’re not really doing your job.

I’m talking more about confidence.  Cojones.  The guts to ship early to a market you understand.

The true challenge is having the nerve to ship your software before the entire scope is complete.  As a rookie leader, you likely won’t understand that your software team can ship a quality product with the minimum possible feature set that will bring business value – even modest business value – even if it’s only to a percentage of the total market opportunity you’re shooting for.  You probably won’t think it can be accomplished as a continuous incremental improvement of features over a time period of x-months or years.  You’ll be more inclined to want everything – you’ll want the whole scope, first time, and ship that with a huge boom – you must, as a rookie, obliterate the competition with one crushing blow.  Or, maybe yours isn’t an ego issue. Maybe you’ll want everything because you’re not confident enough in your understanding of the market and users; so best hit them with everything and maybe something will stick.

Either way, Big Rookie Mistake.

Wanting everything is obviously the wrong way to think about it both from a technical and business point of view.  The fact is, it actually takes a great deal more courage to be laser-focused and put your product out to market with a simple, lightweight vision to accomplish a few targeted things to a clear and strategic market.  There is much more of a calculated mastery in that.

And, sure, you will continue to have a product backlog of great, innovative ideas to add to the product over time.  Believe me, there’s time for that.  What the more experienced Business Leader will know is that: getting your more precicely-focused product to market accomplishes four important things:

  1. You now have commercial adoption of your product. (Reduced risk)
  2. You’ve minimized the investment needed to generate revenues. Your product is now out there making money, and you’ve spent a fraction of what your total scope will cost. (Increased ROI)
  3. You are now receiving valuable customer feedback on your product, which will help you further prioritize the next features to add. (Strategic market information)
  4. You and your team have proven that you can build and ship successful software. (Time to celebrate

Prioritize

Ok, so now if you don’t want to fall into this trap, what do you do?  The key is to prioritize the backlog.  You have 100 innovative, killer features you want to put into the product, but you only have room for 10 this realease.  Someone has to take ownership of which 10, and in what priority.  Then prioritize the next 10, and so on.  Maybe the remaining 90 will change after you’ve shipped the first 10. That’s a good thing.  KeepThis is the Key prioritizing the next 10 (or however many you choose). Have a look at this article by Dennis Stevens on Capability Analysis for some good insight on prioritizing features.

Who owns that?  Typically your Product Manager or Product Owner. Maybe you do.  Whoever it is, remember, one of the most important things for a software development team to be armed with is: What To Do Next.  Mike Cohn has some sound ideas on the Product Owner, backlog and other gems to help gain more context with this.

Stay tuned for Rookie Mistake #4.

Chris Ronak

Advertisements