software III

Don't pee your pants for nobody

This one is pretty similar to the "you'll regret the hack" thing, and I see this a lot with green developers.  With deadlines looming and a rush to get things done, you may be tempted to degrade your work from "software product" to "proof of concept".  What this means is that you're no longer building a software platform you can add to later, instead you're building specific features to try and get somebody off your back.  It works out a lot like the old metaphor about peeing your pants for warmth.

you're warm for a while, anyway...

Essentially, you solve your short-term problem but wind up with a bigger, long-term problem.  This is bad when it's a team decision, and even worse when a developer does this without telling anybody.  I've personally been in the situation where one of my developers did this sort of thing and I wasn't close enough or careful enough to know that's what was happening.  Once we got past UAT (user acceptance testing) and I started rattling off the next steps and new features to add, he turned defensive and told me he needed a few months to rework everything because everything he had just done was purpose built to get past that first deadline.  He literally set us back 6 months and absolutely destroyed my trust in him.

Hire fast, check-in faster, fire fastest

Back in the games days I had an employment model that was built around the fact that I had no idea how to hire people.  In retrospect, I was probably ahead of my time, since research seems to indicate that interviewing is almost worthless, GPA is a poor predictor of work performance, and things like pedigree and credentials are over-rated.  This was before I had ever heard of a behavioral inteview, much less experiened or conducted one.  Since I worked in computer games, every job opening I had was flooded with candidates, and often these candidates were non-traditional.  They were often wiz-kids with no college or formal training.  Sometimes they were older folks with a passion for gaming.  Some were hobbyists who wanted some extra income (that was fine, I had plenty of contract-work jobs available, too).  The hard part wasn't finding people, the hard part was knowing which ones I could count on.

This was especially important for my projects with really short timelines and really tight budgets.  One really flaky developer could derail the entire project (and with it the budget and with the budget my paycheck for weeks or months).

The approach I came up with was "Hire fast, check in faster, fire fastest".

I googled "you're fired" and somehow this image came up.  It somehow seems better than anything else I could have put here.

Basically, I gave a job to anybody who wanted one.  Every new employee would get a single work product to deliver and two weeks to deliver it.  The work product was always something I actually needed and something that I knew could be done in two weeks.  Anybody who didn't get the work done on time was fired.  No questions asked, no conversation, no excuses.  What I had learned was that anybody who is willing to flub their very first impression will continue to disappoint thereafter.  Honestly, this got rid of around 80% of the people I hired.

I've applied this rule in a general sense in many ways since.  If I'm looking to hire a painter and he shows up late to discuss the quote, I take him out of the running.  I once had a buddy ask me to help him find a contractor to build a block wall around his house.  The guy showed up 30 minutes late and I told my friend not to hire him.  My friend did anyway and since I'm telling this story here, I'm sure you can imagine he never got his wall.

Hit the easy problems first

There's the rule when you're playing pool.  When one of your balls is sitting right on the pocket, you don't shoot that shot.  It will probably get knocked in on its own and you're really just wasting a shot.  That mindset is completely misplaced here.

a tempting but misleading metaphor!

Really this is probably just a good project management thing.  If you leave the little problems until they end, nothing good can come of it.  If they really are little, you'll just have a shit-ton of little problems to sort through and fatigue will build.  If any of them turn out not to be little problems (and some of them will end up a lot bigger than you originally thought) you suddenly have big problems that you weren't expecting, popping up right at the end of your project, when you don't have time to course-correct effectively.

Do those little, easy-looking things as early as you can.  Sprinkling in small wins helps to keep you from getting worn down on big projects.  Also, it gives you the chance to adjust your timelines or features if you wind up facing some big, unforeseen shitshow!

this thing again

software development II

You will always regret the hack

Every project gets hairy at some point.  Deadlines start to loom, customer requirements start to tighten, subcontractors and ingredient suppliers are late or flake out entirely.  The team gets stressed and the iron triangle reminds you of its immutable force:

the ol' iron triangle

Adding resources at this point never works.  Even if you have some ninja team of superhuman developers in your back pocket, they won't be able to parachute in at the last minute and do anything right away other than churn the project and introduce more problems.

Slipping the schedule is always tempting.  Reducing features is often what happens.  Sometimes we're smart about it and try to stage them together; reduce the features in the first release, with a schedule for releasing the remainder of the features in the future.

The worst thing that happens is when the decision is made to fight the triangle and keep the same schedule with the same features.  When that happens something else gives--Quality.

In software, when quality slips this usually means that the developers start to introduce hacks.

Magic numbers start to appear instead of declared variables.  Convoluted blocks of nested code get tucked into other functions instead of broken out into separate functions.  Blocks of code get commented out.  Blocks of code go undocumented.  Temporary variable names that make no sense get introduced.  Single purpose design takes over and expandable, scalable features fall by the way-side.  Unit tests and BAT tests go unwritten.

Your software product effectively gets downgraded to proof-of-concept.  When you need to build more later, you're instead spending time refactoring the junk you slapped together.  When users find errors it takes 5x as long to troubleshoot.  At the end of the day, you give up a lot more than you gained and always, always regret it.

Software Development

I've been doing professional software development of some kind or another since the mid-90's.  I wrote my first program on a Timex Sinclair when I was 10 years old, and taught myself Assembly to try to squeeze more into the 2K of RAM it came with.

pictured here with the 16K RAM upgrade!!  That changed everything!!

A lot has changed since then (thankfully).  Along the way I learned a lot of lessons--all of them the hard way.  Looking back at my first attempts at building a company, developing a brand, organizing a development methodology and cultivating people I realize I did things about as wrong as I could.

Here are some of those lessons.  Maybe you won't have to learn them the hard way, too...

Produce excellence, especially when you're not asked for it

My first commercial products were euphemistically called "Casual Games" or "Budget Extreme Sports Games" or more correctly "Shovelware".  Google "Extreme Paintbrawl" and read some of the reviews.  Enjoy the laughs and then come on back.

Extreme Paintbrawl and the games like it were precisely what our publisher hired us to do.  One important guy at a publisher told us "You could literally take a shit on the CD and I could sell it with the right licensing, just get them done as fast as possible."  So that's what we did.  We banged out junky games as fast as we could, because that's what we were hired to do.

This kept the lights on, and kept our customer satisfied, but it didn't lead anywhere.  Later on, when we tried to land bigger, higher-quality projects, nobody was interested.  We had a reputation for producing junk games at light speed.  Literally nobody would give us a shot at producing a quality game with more time and more budget.  In retrospect, they were probably right.  We had a shovelware culture and I'm not certain we could have turned the corner.

At the same time, a friend of mine with a very similar company and very similar starting point aligned his people around producing beautiful, compelling games.  He had the same customers, the same deadlines and the same budgets.  They were late all the time, the games were completely over-engineered relative to the spec, and they didn't make any money on those games, but they proved that his group could do really nice work.  They successfully segued into AAA games while I wound up throwing in the towel and leaving the industry.

Get a monkey on a football

On one of my early projects we had to develop a considerable amount of development infrastructure from scratch.  We were building a new rendering engine, new level design tools, new asset management tools and were working out of a basement.  Weeks went by with no visible progress to show the customer.  They started freaking out and threatened to cancel the contract.

I came up with a schedule of visible milestones to deliver to the customer.  For the first one I said "Look, I don't care if we render a monkey riding a flying football around the course, we have to show these guys something!!"  "A Monkey on a Football" became our catch-phrase for tangible customer deliverables that may not be completely required for the technical aspects of the development, but are completely required to make sure that your customers know you're moving forward.

It is a lesson I should have internalized from an earlier interaction with a guy named "Joris" in the Netherlands.  Joris had worked for us before and we hired him to write the AI for Santa in one of our early projects called "Nuclear Winter".  Joris kept telling us he was making progress and we kept believing him without demaning tangible proof.  When the time came for Joris to turn in his code, Joris disappeared.  Then he turned in corrupt zips, then disappeared again.  Eventually, Joris admitted that he hadn't done any work at all.  He had spent his entire advance on phonesex with some woman in Kansas that he was in love with and he needed more money from us and then he promised he would get right to work.  

So now, I always demand a monkey on a football from the folks who are working on my team, and I always give a monkey on a football to my stakeholders.

I have a few more, but my blogging time is up for this week... I'll post them another time.

options in the wild: part II

At the very beginning, I did a straightforward ROI type of analysis.  The decision seemed very clear from that perspective.  There was one line that took a little more work to get to, but was half as long and had twice as many windows operating.  It should have moved twice as fast.  Easy choice!

I hadn't considered the uncertainty in the model.

The people in line "d" were long a call option on all of the windows to the right.  If any of the windows from "e" through "h" opened up, they could easily exercise that option by walking over and moving to the new line.  I hadn't thought of that until it happened!

Once window "e" opened up, I sat there considering moving to line "e", thinking they might open up "f" or "g" or "h" and I didn't want to miss that opportunity, even though it meant moving to the back of the line.  I decided I was pot-committed to "b" when the other option in the mix made itself known...

The crew of any plane that happened by was long a call on window "a" and "b"!  Since I was in line "b", I was effectively the counterparty and short a call on those windows.  When the crew turned up and took over the windows, they exercised their call and my line came to a stop.

This story is a pretty good representation of the value of using a real options decision framework for a couple of reasons.  The most obvious reason is the importance of involving uncertainty in your decision.  If nothing had changed, my first choice was unquestionably the best.

The second reason is the importance of having a dynamic decision framework that can adapt to new information.  It's easy to make a straight-forward ROI type decision when you ignore the changing world.  One line was served by two windows and was half as long!  That's an idiot-proof decision!  A few minutes later, the decision was more complex.  I was at the end of a line that was roughly the same length as the others, but didn't have the advantage of more windows possibly opening up.  A few minutes after that, I was at a stand-still.  A robust, options-based decision framework that encapsulated the upcoming decisions would have helped.

From an executive decision making perspective, this sort of decision tool is almost never available.  What can be available, however, is some intelligence about what the inflection points are.  If I had any idea about the chances of another window opening up, or what the chances of a crew showing up, I could have produced some heuristics about comparative lengths of each line and made dynamic adjustments to my strategy when the real world changed in front of me.

Options in the wild

A few weeks ago I was travelling on an international business trip.  On the way back I came to the top of an escalator to face the immigration / passport check area.  It looked like this:

(only the lines were a lot longer)

I just jumped into the line that was right in front of me and then sort of observed the lines.  The mental schematic I put together was this:

So I moved through the crowd to line "b" because it was the shortest one I could join (since I don't hold a EU passport).  Also, I realized that there were to windows serving that lane... both window "a" and window "b".  No wonder the line was shorter!

A minute later, the situation looked like this:

As the efficient, German airport had recognized a long line and opened window "e" up, and a mad dash had taken place as people near the end of the line for window "d" scrambled to be at the front of the new line.  My old location at the end of line for window "d" would have put me in pole position for the newly opened window!

Then, a minute later, this happened:

When the crew for some flight showed up and took over priority on window "a" and window "b".

Being a ridiculous person I thought "This is fantastic!  What a great example of real world options analysis!!  I can't wait to write this up!"

What are the options?  Take a few minutes to think about it.  In a few days, I'll publish my thoughts on it, but I would really like to hear what others say, too...

Visualizing your business model

The elements of the business model

If you haven't read my last post about the elements of the business model, do so now.  There's not much sense in reiterating what a prospect is, or how it fits with a product, etc.

Now, check out this picture:

The visual business roadmap

There is a great deal of information in this drawing.

Along the bottom you have the projects associated with your technology (product development) roadmap.  In the drawing I have here, you have two layers--real business can have many more, of course.  The bottom row represents core technology programs.  The layer above that represent product development projects.  Each product development project relies on one or more core technology program.   This is very typical.

Along the left side are market development projects.  These projects are intended to change the appetites and buying behaviors of the markets in general--whether or not you will capture the business produced.  For example, when Apple introduced the ipod the TAM for portable MP3 players exploded.

Along the right side are all sorts of projects.  In a real portfolio this is where most of the decisions really are.  These projects can be things like customer enablement programs, directed marketing programs, and anything else that will impact your expectations around your prospect.  That is to say, anything you think will impact the market share and/or pricing expectations for that product with that market.

Often a project will have impacts at multiple elements of the drawing.  

For example, adding a cool, new feature that has never been seen before may encourage people who would never have bought a product like yours to enter the market (TAM expansion), will help you increase your share of that newly expanded market (MSS expansion) at an increased price (ASP increase) but with the downside of an increased product cost (Cost increase).  In this case, you would be impacting markets, products and prospects all at once!!

modeling your business - projects, products, prospects, markets

What are the fundamental elements of modeling a business?

I often help people figure out how to model and value their business concepts.  A really common concern is "My business is different!"  That rallying call often serves as the number one roadblock people have when trying to build a business analysis.

The fact is this: No matter how different your business is, it's different in one of the same few ways.

All businesses expect to have customers.  All business hope to deliver something of value to their customers.  All businesses do some up-front work in order to have that valuable thing and to make sure their customers know about that valuable thing and to actually deliver the thing to them.  Whether the thing is physical (like a car, a microchip, a refrigerator, a satellite or a pencil) or a service (like a hair cut, consulting, vacation experience, healthcare), or something intangible like software doesn't matter.  The fundamental economics are the same.

If your business doesn't look like this--well you don't really have a business.

So let's take that "my business is different" issue another step.  How is your business not different?

Products

You have (or will have) something that you want to sell.  If it is a tangible, physical product, it probably has some sort of manufacturing cost associated with it.  You should get an idea of how much each unit you sell will cost to produce and deliver to customers.  This is the variable cost of manufacture, or "unit cost" for short.  Unit Costs will sometimes scale as a function of learning curves or economies of scale, and sometimes they'll just stay flat.  Sometimes (like software) this number will be zero.

Fixed Costs

In addition to the variable cost of manufacturing, you'll have overhead.  Maybe you need to build a factory in order to produce your product.  Maybe you need to build a brick and mortar store as a venue for providing haircuts.  Whatever it is, you will have some fixed costs.   This is often called PPE for Property, Plant and Equipment.  PPE will almost always scale with your expected volume, but with the critical distinction that you have to make your investment in PPE before your volume starts to realize.

Projects

Your business will probably require some spending up front that doesn't go into PPE.  Sometimes this is called RND (Research 'n' Development), sometimes it's called NRE (Non-Recurring Engineering), sometimes it's just called "Spending".  Whatever you call it, this is what you have to invest in time and people-hours and other expense items in order to get to the point where you're ready to start bringing your product to your customers.

Markets

You have customers who are (presumably) going to find your product valuable and pay you for it.  Smart companies undergo an exercise called "Market Segmentation", where they try to group their customers together into meaningful groups called markets.  Members of these markets have similar buying behaviors.  They typically value the same aspects of the products and are willing to pay similar amounts.  For purposes of business forecasting, you should take an "outside in" look at your markets and a great deal of your analytical work will be done just trying to size these markets.  How many potential customers are there in each market?  How many of them will make a buying decision in any specific quarter (or year)?

Prospects

To build a predictive business model you need to make forecasts about how well the products you're creating will be received by the markets you have characterized.  This is a "Prospect" -- the specific economic expectations for an individual product with an individual market.  You will spend most of your business analysis time on forecasting prospects.  When will this product hit this market?  How much market share can we hope to achieve?  How quickly do we think we will achieve our peak market share?  How long before we see that peak share get eroded away--either cannibalized by our own subsequent products or defeated by competitive ones?  What sort of prices will we be able to command for the products?  How will the price and the market share forecasts interrelate?

These are the fundamental elements of analysis for any business.  

Before folks should start thinking about how their business is different and how their model won't fit into a typical analysis, they should address these questions and frame the business through these lenses.  After these basics are sorted out, you should start worrying about things like competitive timing, synergies and roadmap effects, market saturation and disruptive effects, complex pricing structures and so on.  Normally those sorts of details won't move the needle on the big analysis.

This isn't to say that the more detailed analyses aren't necessary.  If you're in the middle of negotiating tiered pricing discounts with an important customer you should really figure out what those will mean to your revenue and NPV expectations.   Those things can wait until later.

Next time I'll put up some materials one the mechanics of using these essential entities to create an NPV.