Features Don’t Make Money, and Yet They Do

In my line of business, we often get customers who say, “If your product only had this great feature [that I need] it would really sell.  You’d make a million dollars!”

Such enthusiasm prompts us to run off and produce the requested feature as soon as possible.  And when we do…  Nothing happens.  Nobody’s there to heap praise on us and pay the big bucks.  The product doesn’t sell any better than before, and no such millions are made.  It begs the question: do new features make money?

Certainly from a short-sighted standpoint, the answer is no.  There are no crowds of new customers clamoring for the new feature.  In fact, most evaluators simply take the new additions for granted, and only stop to comment when something they want is missing.  No praise is given for products with great new features.  But lots of crap is shoveled out when something isn’t there.  That’s just normal human nature.

But over the long term, a constant flow of new features that solve customer problems is a good thing.  It builds your customer base and takes the heat off sales and support staff.  View it as a long-term investment that will eventually pay.

 

— newshirt

Define: Make Verses Buy

Make verses buy: The act of building a product for your own internal use as opposed to licensing a pre-existing product.

 

Organizations with the ability to produce their own products are often tempted to build everything, including the tools they use.  This is most common with software companies.  They have a bank of software developers, some sitting idle awaiting jobs, and the company is tempted to use those resources to build all the tools they use.

I once worked for a software company that wrote their own compilers and debuggers.  For internal use only.  Yikes!  When Microsoft sells compilers for less than a thousand bucks, this doesn’t sound cost effective to me.

Again, the temptation usually stems from developers sitting around on their hands with nothing to do.  Why not put them to work building internal tools?  My opinion: bad idea – almost every time.  Those developers are saving the company very, very little money.  After all, off-the-shelf software is cheap.  So, divide the number of hours they work by the cost of the software, and your developers are only making a dollar an hour.  Better to put them to work in customer support or sales, cold calling for gigs.

The real killer comes when the software they wrote needs bug fixes and maintenance.  Are those same developers still available?  Usually not.  So who pays for the bug fixes?  You.  Was it still cheaper to write your own stuff?  I doubt it…

 

–newshirt

Where My Ladies At, Yo?

Yo, dog…  Where my ladies at?  Got me a grip a cash an’ a HP blade.  I’m a IT professional!  But where my womens at, yo?

I’ve decided to convert this blog to attract the hip hop community.  Especially those from the IT industry.  How am I doing so far?  No, really, I’m just wondering where the fine ladies are at in the IT industry.  Coders, network admins, dbo’s, project managers.  There’s only one for every four men.  That’s right, about 25%.  Check out the links below.

http://www.cioinsight.com/c/a/Past-News/Numbers-Show-Big-Decline-of-Women-in-IT/

http://news.zdnet.co.uk/itmanagement/0,1000000308,39352947,00.htm

 

I have my own theories about the disparity in numbers…  To me, the ideal IT employee nests in the server room amongst the network cables, routers, and modems.  He beds down with a blade under his pillow – an HP server blade that is.  Occasionally – usually on a full moon – he emerges to shower, change his crusty socks and underwear, and prowl for chicks at the all-night gaming bar.  He writes a staggering mountain of code, making dark hackers look like kiddie scripters.  In past lives, I was that foul-smelling geek – so I know.

Now,,,,,,,,,,,,,,,

Show me a girl who wants to live like that.  Sure, I’ve seen lots of nice professional women in the IT industry.  They wear nice professional suits, and make their hair up in nice professional styles.  They’re nice.  Professional.  But they don’t “live” for the bits.  In my 25+ years in the biz, I’ve never seen a true geek chick – one who codes until her eyes run and sleeps under her monitor.  (Yes, I’ve actually bunked under my computer desk, and so have some of my friends.)

Once an IT department gets a few guys like that, they don’t the respect the “nice professional” types.  I’m sorry for the crude characterization (and maybe I’m dead wrong), but passion for the bits still sells, not professionalism.

 

Peace Out,
–newshirt

Engineers Hide Risks

Every project manager knows he must identify project risks, document them, and resolve each one.  In other words, he must learn what could jeapardize the duration, budget, or quality of his project.  If you don’t, the project may fly off the tracks and you’ll look bad, or worse.

Problem is, your engineers are hiding those risks from you.  The fictional dialogue below shows how it happens.  It is a faux conversation between your project manager and one of the engineers on the team.

PM: “I love your new designs!  This project is really coming along.”
Eng: “Uh-huh.” (hoping to be left alone.)
PM: “Do you think you’ll be finished by October.  Big deadline you know!”
Eng: “Of course.” (barely lifting his head.)
PM: “Any risks or unknowns?  How about that integration task?”
Eng: “Nothing I can’t handle.” (peering deeply into the montor.)

Engineer-boy has two problems.  First, he’s a little too independant to admit he needs help.  Secondly, he won’t risk the tarnish to his stellar reputation.  No white-shirt, tie-bearing, non-pierced PM will ever get him to crack.  He’ll work all-nighters if he has to, or so he tells himself.

 

–newshirt

Advice: Create Layered Products

Project management advice: Create layered products that allow you to release new updates once a month.

 

I was originally planning to title this post ‘Create foundational products’ and then I quickly realized that the foundation is only the first layer of this strategy.  I’m advocating short, quick releases, in layers.

I’ve found that big, monolithic product releases have several downsides.  They are often riddled with bugs and usability issues, and sometimes require several slipstream releases to resolve all the bad stuff.  Developers bite off more than they can chew, and the product becomes so complex that complete testing is not possible.

Small, frequent releases solve this problem.  With each release, you have the opportunity to fix prior bugs and advance the grand design a little further.  True, you can’t toss out your ‘take over the world’ design in one giant release, but given some patience, you’ll get there.  And the product will be a lot more solid when you finally reach that point.

Start with a simple foundation.  It probably won’t have all the features customers are screaming for, but it gets you started.  Follow up with several small releases that fill in the gap.  Listen to beta users and customers, and build the grand design with their input.  Trust me, you’ll be a lot better off in the end.

 

–newshirt

How To: Create a Milestone in Microsoft Project

Milestones are a necessary element of project planning.  They let you stop and evaluate.  Have the objectives been met so far?  Is everything ready to proceed to the next step?  If so, we have achieved a milestone event, and the next phase can begin.  Here’s how to create a milestone in Microsoft Project.

Start by creating three tasks.  Notice that the third task is a zero-duration task.  That is considered a milestone in MS Project.  We’ll be linking into this task so that it gets pushed out if any other tasks go longer than anticipated.


Milestone Task in MS Project

 

Select tasks to link them.  CLick in the selection column to select an entire row, then Ctrl+Click in another row.  Click the Link button to link them.


Selected Tasks

 

Link and move some to illustrate the milestone.  Here we see both tasks linked into the milestone.  If either task is delayed, the milestone will be pushed out.  When the milestone date arrives, you should evaluate your project to make sure it is on track.  Then you can proceed to the next phase.


Linked Tasks

Advice: Have a Project Champion

Project management advice: Every project needs a champion.

It took me a while to understand the nature of product development and the need for project champions.  At the beginning of my career, I believed projects just “got developed.”  I was working in a research department at Eastman Kodak Company, building cutting edge photocopiers.  Engineers buzzed around, building microprocessor-based circuits, image-enhancing emulsion, and writing software.  I did my part and just expected the product to come together.  Looking back, I now realize there was one man who made it all happen: a gray-bearded old dude who wanted to change the industry.

Products get developed, and projects finished, only when there is someone with the burning desire to see it happen – like the old bearded dude in the example above.  A paycheck is not enough.  You have to want it badly.  Only then will you fight through all the obstacles to make it happen.  Projects often take 2-3 times their original estimates, and some required several iterations to realize the full glory.  And only a true champion will endure the suffering to see it to completion.

Look around at your project.  Do you have a champion?  A person who refuses to give up?  If not, you have good reason to fear that the project could be canceled or back-burnered.  Have you personally ever been a project champion?  If not, give it a try.  Throw yourself into something that really engages your passions.  You’ll find there’s satisfaction in a job well done.

 

–newshirt

The Bluebird: Model of Efficiency

Just for fun, I’ve posted a picture of a bluebird one of my customers sent me.  This picture was taken with a nest-cam outside one of his birdhouses.  Did you know that baby bluebirds go from hatchling to flying machine in only 18 days!  That’s a model of efficiency!

 

That’s right!  This bluebird is only 18 days old!  Like a machine, every cell in its body knows whether to contribute to flesh, bone, or feather within three weeks.  And then it’s off.

I want our project management organization to work this efficiently – like a machine.  Ever hear of Intelligent Design?  The theory essencially says that when a thing looks like it was designed, then it was designed.  To me, the bluebird looks like it was designed.  So who was the designer?

Can our projects run like they were designed?  Like a grand plan set forth in seven days and then implemented with flawless execution?  That’s the way I want our products to flow.  Wasting time “figuring things out” slows growth and limits potential.  Instead, let’s model our projects after the bluebird!

Okay, that’s a litte simplistic…  Which one among us is God?  We are flawed beings, and our products and projects reflect our limitations.  But we can still strive for it, can we not?  Flawless project execution…  That’s my new goal.  🙂

 

–newshirt

Special Features for Special Customers

Our company develops a line of products.  We sell the same off-the-shelf design to many customers.  They all essentially get the same thing: a downloadable product with a certain set of features.  But there is always somebody that needs something a little different.  That’s when they become “special.”

Developing special features for a single customer can pose special challenges to an off-the-shelf product.  This post discusses three of those challenges.

My biggest concern is punishing 99% of the customers with a feature that only 1% will use.  Suppose you add a new feature to the product that 1% of your “special” customers will use.  The other 99% may not understand it.  That’s a bad thing.  They’ll think they need to understand it, and will spend time studying it, only to learn that it does not apply.  My advice: make sure that doesn’t happen.  Bury it where only the most adventurous will find it.

The next concern is maintenance.  If you create a new feature for one customer, guess what…  You’ll have to make sure it stays working forever.  It will cost you money as long as you maintain it.  Make sure you get that money up-front, or in maintenance payments along the way.

Have you given any thought to the effect your “special” features have on the rest of the product?  In other words, will these one-off features break something else.  The more complex a product is, the more likely collateral damage will occur.

The upshot is that special features cost more money than you might think.  But you have to do them to gain new customers and satify existing ones.  It’s all part of the game.  Just make sure you are profitable doing it.

 

–newshirt

Our Customers Do Our QA

This is not as bad as it sounds.  A lot of companies are in this boat.  They don’t have the revenue to hire full time QA engineers and testers.  So, they do what they can and rely on customers to report bugs, oversights, and possible enhancements.

Let’s briefly discuss how a ‘real’ QA department operates, and then contrast that to the poor-man’s solution.  Normally, a QA manager and team of testers ensure that products delivered straight from the engineer’s drawing boards ship with minimal bugs.  Each tester is assigned one or more areas of the product.  They follow a QA plan and checklist.  Every feature is scrutinized, often put through the paces as real customers would use it.  Bugs are sent up the chain, through the QA manager, and back to the original engineers for fixing.  Once resolved, QA engineers verify the fixes.

A QA department is nice to have.  They find hundreds of issues, and save the company a lot of money and embarrassment.  Product defects are resolved before they hit the shelves.  In the end, the QA department is usually worth their pay.  After all, that’s why the department exists in the first place – to save the company money.

But if you can’t afford the salaries, and you have a small number of customers, the development and manufacturing engineers will need to perform the dreaded duty.  (It is monotonous work.)  Problem is, engineers bristle at repetitive tasks like product testing.  They won’t do a thorough job, and you still end up getting bug reports from customers.  Plus, you’ll have to pay the engineers for their extra testing work – and they aren’t cheap.  Bugs that reach the outside still cost you money in customer dissatisfaction and lost sales, but perhaps not as much as the salaries for a full testing crew.  That’s the real gamble.  And, there are so many intangibles that a true cost analysis of each method is difficult.  But, you’ll know when you need a QA team – when customer complaints begin to kill your product momentum.  When that happens, put together a team quick!

 

–newshirt