Archive | Scheduling RSS feed for this section

Speed and the product lifecycle

23 Feb

If you’ve looked at any of the material on technology products, you’ll have seen this curve:

Innovation adoption lifecycle

To a first approximation, this tells us how fast a product will sell over time, and knowing about the types of people in each of the segments will tell us how to tailor the messages we put out about the product.

I did a spreadsheet to see what happens.

profit_no_devel

Wonderful. Look at all that lovely profit.

But before we can sell something, we need to develop it.

Let’s add some development time into the project. And let’s remember that we have to borrow the money from somewhere to do it.

profit_devel_6m

Not only do we need to borrow to do 6 months of development, but also we make less profit.

And, of course, everyone wants to make sure that the product is as good as possible before releasing it onto the market.

Bad idea.

So they make the product better – and it sells 50% more than it would have done. But they take 50% longer to do that.

profit_devel_9m_more_revenue

Ok, we made slightly more profit. But it happened later, and we got more in debt to do so.

And what happens if they were wrong about the value of the features? What if we didn’t sell any more?

profit_devel_9m_same_revenue

Ouch. We don’t break even until right at the end of the product’s life.

Now, to be fair, there’s a fair collection of assumptions in those graphs, and I don’t pretend they are anything like precise. But that does look to me like a really strong argument for getting the minimum viable product out as quickly as possible. Now I get to try and explain it to the engineering team…

 

Advertisements

“Move fast and make things” – up?

28 Dec

There’s a great picture on Fast Company of Facebook’s “Minister of Propaganda”:

Note the poster in the background. And the one on the floor to —-> that side.

One of the challenges about being in the “building complicated things” business is that nothing happens quickly. Making a brand new complicated thing takes months. Or years. (Even if you’re putting a man on the moon for the first time.) And it needs a whole host of people all pointed in the same direction for all of that time. Which means someone’s got to feed and clothe them, and that normally implies someone somewhere is going to be paying people. Before you know it, you’ve got a burn rate like a cliff and you’re headed straight into the ground. (Which is why some of the best hard SF has a project manager as the lead)

Software, in some sense, gets it easy. Entire schools of endeavour are devoted to ways to make people believe they experienced software. Then they just buy apps or OS X and eternal upgrades promising what they thought they bought. Damn their slick marketing promises and the joy their customers feel for that.

Persuading engineers that they can buy something that they have never seen before, and your own engineers don’t know they can make – that’s a sales role. J.R.Bob Dobbs is my key text on this – he is apparently responsible for a large part of the US and USSR space programmes after being off-loaded with ten billion tons of ¬†fuming nitric from a dodgy mil-surp deal from Peenemunde.

I’m looking forward to the future promise of 3d printing as changing engineering. CNC machining had the same sales pitch, and if we’re lucky we’ll see the next generation of engineering promise in another 50 years.

Now, back to trying to make atoms and bits cooperate en masse.

[Unless this was all the difference between generating something new, real, complicated that acted in the world – and just making pixels dance on peoples screens …]

Plans and goals, #1

25 Dec

On average, about half of your to-do list gets achieved.

I always see this as an opportunity in waiting. Add “Cure cancer”, “achieve world peace”, and “transmute lead to gold in an energy-efficient way” to a 3-item list, and either you’ll change the world or you’ll get the rest of the list done.

Currently, I keep a long list of GTD-style “next actions” from a long project list, which might get done opportunistically, and a short list of things to focus on in the next few days.

The long list lives in an Emacs ORG-MODE file, and the short lists are always on nearby pieces of paper. Sometimes they get archived to track what happened when, ¬†and sometimes they just recycle naturally…