Comments on: Competing on the Basis of Speed

By: chris

chris — Fri, 22 Jan 2010 06:28:44 +0000

Thanks for the comments, Sue!

I guess there’s a few problems I see with your reasoning. In your first comment, you mention that the back-and-forth between developer and customer is a “bother”. For software that can be very precisely defined (math computations, etc.), a single up-front specification from the customer can be sufficient to deliver an acceptable package. But if you sat down and describe how you wanted a website to look, and then I went away for 3 months and built it, and then showed you the final result, it’s almost guaranteed that you’re going to find some issue. Perhaps you under-specified something. Maybe you thought that purple and blue would look good together, but they don’t. Perhaps you just changed your mind on something! If you had been going back and forth with me, where I showed you interim bits, we would much more quickly converge on something that you find acceptable.

Option C in your second comment would be great, if it was always applicable to software, but often it just isn’t. If you plan something for 6 months, and then build it and it doesn’t line up with what people want, market research won’t always help. Sure, reading up on a target market is important, and getting people to fill out questionnaires can help, but it’s still just speculation. Getting *paying customers* on a product gives you real, live validation.

Of course, there’s examples on either side of this. You may say “Well, Apple goes dark for a while, then comes out with awesome software / hardware – why can’t you just do that?” Well, sure, that’s one data point. Microsoft does the same thing – how did you like Vista? Google routinely does the early release thing (think Gmail’s 5 year beta).

This is greatly eased when there’s an easy flow of communication between developers and customers. Developers *should* be close to customers, otherwise the back-and-forth really does become a bother. If one our customers wanted to have an improvement to our new feature, they don’t have to call some outsourced tech support, working their way up the chain until they reach an ombudsman, who will relay a version of the request to a senior product manager, to a technical product manager, and so on down to a developer. If they did, the gist of the customer’s request would be totally changed due to all the handoffs! As a development manager, I see customer requests as written by the customer. I have their phone numbers and email addresses. We have the power to deploy specific versions of our software to specific customers, helping us validate features without impacting others. Our customers see this as a *fantastic* thing, and anything but a bother.

Software is different in a lot of ways than other product development. If you’re interested in learning more about it, I’d have a look at the Agile Manifesto as a start, watch the video above, and, of course, ask me more questions! If you really want to see an extreme version of shipping fast, have a look at Eric Ries’ idea of continuous deployment. His company (and a growing number of others) ship code to customers up to 20 times a day – every change gets shipped! He’s made a whole lot of money doing this, and his customers don’t see it as a bother either.

By: Sue

Sue — Fri, 22 Jan 2010 03:35:50 +0000

Now I note that your next paragraph suggests that the complete FeatureX a few months from now might not be complete anyways. What’s the point then? If these were my choices:

- rudimentary FeatureX now that doesn’t have what we wanted, with updates later
- complete FeatureX later with oops we weren’t quite complete before updates later

Sorry, but I’d have to go with C, none of the above. In this case, you should have done more market research ahead of time!

By: Sue

Sue — Fri, 22 Jan 2010 03:33:13 +0000

From a business point of view, I’d have to say you may be jumping to conclusions about whether a business would want the rudimentary FeatureX now or the complete FeatureX in a few months. I’m not saying this is true for ALL businesses, and I don’t know the context that you’re coding for. All I know is, a business decision maker would sometimes prefer to have a known quantity complete but have to wait a defined period of time. The problem with having a rudimentary thing is that it involves an extra update later; your people may not get what you want so you have to be bothered back-and-forthing with the developer to get it right. Sometimes you just want the whole enchilada in one go, and a bit of an extra wait is worth it.

I’m not saying this is true in all cases, but it might be true in enough cases to scotch your assumptions.

By: chris

chris — Sun, 10 Jan 2010 20:35:06 +0000

I’ve now remembered where I’ve heard a lot of this before – see Eric Ries’ article on validated learning (http://www.startuplessonslearned.com/2009/04/validated-learning-about-customers.html).

By: luke

luke — Sun, 10 Jan 2010 19:19:23 +0000

Right. I guess what’s hard to measure is the cumulative effect of leaving areas unpolished. I would argue it’s way way easier for the business to always choose “new feature X” over incremental improvements to old features. But then you can get to a point where the unpolished parts start dragging down customer satisfaction (not very tangible) and team satisfaction (eg: proud of your work, again not very tangible).

Having said that, I don’t disagree with your analysis. We can’t do everything, right?

By: chris

chris — Sun, 10 Jan 2010 19:15:07 +0000

@luke Absolutely – and that’s not necessarily the bad thing. It’s a fine line – you need to make sure the feature you ship is good enough to get people using it. Ideally it would drive sales, though with a very experimental / proof of concept feature this may not be the case.

The thing is, if the business looks at it and says “We have a $1 million sale riding on developing NewFeatureY, and only $250k riding on improving OldFeatureX”, then they are entirely justified in not going back to tweak and polish. In business, everything (including development) should be looked at from the business perspective – that’s one of areas that Lean stresses and that is sometimes left out of descriptions of Agile.

Now, if the business guys are just ignoring customer pleas to improve OldFeatureX in spite of it making business sense to do so, you need new business guys

By: luke

luke — Sun, 10 Jan 2010 18:31:37 +0000

In my experience the problem I run into in this kind of situation is where we ship the minimally functional pieces, and then the business moves on to other feature sets and we don’t return to do that tweaking & polishing for a long time. From the business perspective, it can be very tempting to move on.