Archive for March, 2013

Twinkle, twinkle, little product

March 29, 2013

So we’re far away from the city; the night is dark; the moon is full; the light sufficient; headlights off; just us and the sky, a wide and twinkling sky; and our car moving us beneath the glorious heavens. The stars twinkle. We recall the old rhyme, as the sky takes our breath away.

A few nights later, some of the staff is working late to meet tomorrow’s deadline, so you’re doing your leadership thing while you lose yourself for a moment looking out your skyscraper window. The stars still twinkle. The moon doesn’t. The streetlights don’t. Only the stars, the few you can see standing in all that light pollution, twinkle.

Years ago, decades ago, the astronomy community realized that they had to move their telescopes and other scanners out beyond the atmosphere if they were going to get rid of the bugs we call twinkles. Once they got the Hubble up there, the stars no longer twinkled for astronomers. With the bugs gone, they gained clarity. They gained vision. They gained insight. They moved their value chain beyond one of its constraints, and went on to capture that value, deeper value.

Astronomers can hardly be blamed for those twinkles, those bugs. Those twinkles arose from a physical constraint, the sky. Managerial decisions wouldn’t have made those twinkles go away. Quality assurance wouldn’t make those twinkles go away. Better astronomers wouldn’t make those twinkles go away either. Twinkles persisted until recently.

But, I said product didn’t I? How do our products twinkle? How do our products twinkle despite management, programmers, quality assurance? And, I’m not talking about the bugs that could just as well turn up in a telescope rather than our code. I mean the twinkles, the bugs, we are blind to; the politics of product and the politics of elicitation; the politics of governance; the CEO; the execs; and the management of the software vendor organization; yes, right to your door, that of the product manager; and beyond that the politics out in the distance there, the politics of the economic buyers that constitute our customers; and our early adopter clients and their organizations management. Call them, the air of the development world.

In recent tweets, I’ve had to remind peeps that, in my world at least, that of companies that sell technology, rather than content, aka not a web 2.0 company, the economic buyer is only the first buyer, the person in the initial sale, and given the enterprise nature of the pursuit of our increasing returns, not a person involved in the subsequent sales, not a person that will even involve themselves in the UX. That economic buyer does, however, get sold some notions of business value, and lacking that might snap back and see to it that our application is removed from their company. That economic buyer is at the apex of the purchasing company’s politics spreadsheet. That economic buyer is the twinkle supplier.

Software development is repleat with myth. Requirements are never stable. But, that flies in the face of those of us who worked in functional domains. Our requirements rarely change. We’re mostly about reproduction, doing it again and again and again. And, meaning wise, our meanings rarely change, so don’t look at your elicitation sources as the sources of twinkle. And, absolutely–what that myth tell us is that requirements never stop twinkling? Like stars photographed from the ground, the twinkles stop, because we fixed them in silver. Requirements fix them in words. Developers never see the twinkles until a project turns into a program, or in a more Agilist world, the next iteration or refactoring.  Even then, developers are far away from the nuclear furnace.

The twinkle, twinkle, in an internal organization, requires us to look up. And, don’t talk to me about flat organizations. If an organization was really flat, my CEO would be shopping at Walmart and wearing those t-shirts they give us, so we have clothes to wear at work. There is always an up. And, in a vendor organization there is a down. Flip the representation over if you like. Source politics on one side and builder politics on the other. Twinkle, twinkle–southern hemisphere, northern hemisphere–matters not. That politics is hierarchical, deep, and fused. The end results are tradeoffs. We talk about tradeoffs as if they were necessary and the core of what we do. The tradeoffs keep changing. So the twinkle never ends, and the product fits loosely if at all. Does it serve the economic buyer’s expected value, or the need for users to get some aerobic exercise pushing a mouse across a screen while compensating for the mismatches between the software and their functional cultures.

The twinkle does have solutions–AOP for one. Ask a developer about it, or search this blog. It might be in my prior blogs that are now inaccessible, one of the wonders of SAAS. But, beyond the technical enablers, the booster rockets, we need to get rid of the twinkle, the politics that ruin our ability to deliver value fully. No endless chain of  iterations will eliminate the twinkle. Only we can get our software up above politics. Start by noticing it. Of course, we can dream of the day,….

Back to Blog

March 15, 2013

It’s been over a year now since I disappeared from my blog. I still have no ability to draw the bitmap graphics that I’ve used extensively in my blog, but a writing book challenged me to go completely lexical. Disappearing doesn’t mean that I forgot my backlog, or that new ideas haven’t showed up to extend the universe. But now, I’m back here.

Last month, out of frustration, I started another blog, Product Strategist 2. But today,  I posted a link back there. If you’ve already followed me out to that blog, we will be staying here. Check your subscriptions. Thanks.