They had already published many papers and demonstrated the technology at conferences. Now we were going to turn it into a product and unleash it on our eager market. To do this we had to get practical about the actual features of the product, so understanding exactly what the technology did was crucial. It soon became clear that, like those biographers of Shakespeare, there was some confusion about the subjunctive and the indicative.
I would ask about a particular feature of the technology and get the apparently unambiguous response “I can do that”. I now know that there were three possible interpretations for those apparently simple words:
- “I can do that”; I can already do that, I can do it now, I can show you, I won’t have to wave my hands and ask you to imagine some future state, it’s real, no, really, see … watch
- “I can do that”; I really can do that, I could do it next, I can’t already do it but it is quite achievable and I can show you tomorrow or next week … probably
- “I can do that”; I can imagine a future world in which the thing you describe could be possible and that I might have some role to play in it, in other words, in all practical ways; “I can’t do that … yet”.
I think the problem comes from two significant features of software product development (I’m not qualified to blame the language). Firstly, software is, well, soft. We can change it quickly (usually from working to not), adding and changing features with such rapidity that it is sometimes hard to say what it does and does not do. The second is that really bright engineers who live in this uncertain world can easily imagine all sorts of new and exciting things that the software could do, and they are keen to make that happen (mostly). Yet, we as Product Managers really have to pin it down and understand what is possible now and what might be possible in the future. The sooner you figure out which “can” your engineers are talking about, the sooner the product discussion can get real and the sooner your product can get to market.
I once asked an ASIC chip designer. “When would they put MS Word on a Chip?
“Never.”
When hardware gets hard, they turn it into software. If the technology is a mess, the system programmers leave it for the IT programmer. There is always another layer to leave it for. Surprise! That’s OK, it will be in your layer tomorrow. So it goes.
With some enterprise software, they even pushed the complication out into the business process.
Thanks David,
Yes, you’re right, and even push the complication all the way back on to the user.
Great post, Chris – and very true. Engineers are typically quite eager to prove their technical prowess – and in some cases, think they are serving the users better by simply “giving them what they want” and coding up a feature over the weekend they heard a user mention somewhere along the way.
The danger with this approach, even though it produces new technology rapidly, is that it only ever helps to create a jagged product. The road to hell is always paved with the best intentions; the logic of “a user asked, and I can easily code that, so we should give it to them” is faulty logic.
And while all of the components, modules, and features may be technically proficient or worth discussing at a conference with other engineers, they aren’t digestible by any sort of user, client, customer, or market.
Thanks Adam,
Yes; prioritisation of features based on ease of implementation and whim of engineer! Never mind all the baloney about user need and benefit, nor about ensuring that features fit together in a sensible way and are targeted towards product strategy. Just hack some cool stuff in! No, really, I’m being sarcastic.