Archives for posts with tag: Software

I was talking to a friend of mine the other day, and he was talking about his latest sales opportunity with a big multi-national company. How did they find you, I asked, since his business is quite niche. On Google, he answered. Who’s the customer, I asked. Google, he said.

Now, admittedly, everyone uses Google to find stuff, but this is Google using their own stuff, and it got me thinking about software generally, and those companies that are in the position of using their own software in their daily work.

I’ve worked for a few companies who are in the position of using their own software, and the double-edge sword is this: no-one uses your software more than you, and no-one is using more of your software, in the sense of its full functionality. No-one is using the stuff better than you. You’re designing it, building it, testing it, supporting it, but you’re also a user of it – a consumer of it – yourself too.

It’s useful to remind ourselves in this position that it’s our familiarity with our own stuff that brings this knowledge, so our job is to get our customers using so much of our software, so much of the time, that they approach the same level of familiarity as us and derive the same benefits. After all, with all the different types of software in any business, how much of the full functionality do we usually use? 10%? Less?

It pays us to regularly ask our best customers how they’re using our software too, since they can give us insights and shortcuts about our own stuff that we never knew.

The more of something we use, and the more we use it, the more value we derive.

What do you understand by the term ‘product roadmap’? There are lots of definitions, some narrow and some broad, some internally focused and some market- or customer-focused. And how detailed should a product roadmap be? Should it pin your detailed colours to the mast, or should it be high level, allowing you room for manoeuvre?

I think that over time B2B customers have become somewhat desensitised towards product roadmaps. This is especially true in the software industry where the sheer complexity and number of moving parts, combined with the influences of individual customers, conspire to make roadmap projections aspirational at best and at worst downright misleading and fictional.

The pressures on the business in a dynamic landscape are changing all the time, and I’ve seen businesses where products or product enhancements have arrived 2 or 3 years after they were advertised to come on stream.

But back to product roadmap definitions. The one I use when asked this question defines a product roadmap as a plan of product or platform developments, delivered through a release mechanism – which could be a few or several times a year – through properly managed projects and programmes. After all, you’ve got to be sure that all the parts of the business can fulfil their element of the whole product solution. In other words, the roadmap should really be about when new releases are delivery ready, not sales ready. By all means seed the market, and build the demand to allow for the natural lag of a sales cycle, but publish your roadmap based around genuine availability.

Customers love to see detailed roadmaps, but only if you actually can commit to the associated timings, otherwise the trust quickly evaporates. Just like in sales, you’re only as good as your last quarter. Software development never seems to build in any buffer for the inevitable bumps in the road – probably because the front of the business is pushing for the earliest possible delivery date – and when those bumps occur, it’s very hard to get back on track. That’s why I fall back on the principle of under-promise and over-deliver to customers, and pushing back to the business. The customer comes first, so I’m in favour of high level roadmap pronouncements that strike the right balance between demonstrating progress and allowing wiggle room, so you can be on time, on brief, and maybe even on budget.

When you download a new operating system, or a major upgrade to software, or even a minor update, do you ever participate in feedback? Do you ever send the coding report back to the software originators when one of your applications crashes?

Who has time to do this?

Software gets released. It has bugs in it. You, as a software originator, can’t legislate for every combination of systems and applications running together with your code on every piece of hardware. You’d be testing until Domesday.

So you either upgrade early and put up with the glitches, going onto Google to search a problem and download a patch. Or, you wait a while until the major problems have been patched and you take the release late, or a skip it and take a later point release. You’ve relied on a bunch of people who’ve had the time and inclination to contribute their feedback to make a new piece of software better for everyone.

But who has the time to do this?