notes and views on crm, social media, and the human side of information technology

Hackable business models

IN THE OLD DAYS (before I got my driver’s license), you would buy your Skoda with a thick manual and when things went wrong later - and they did - there was a LOT you could do in your own backyard, using standard tools, to make your car operational again. One of very few advantages of communism: the cars were so simple you didn’t have to be a mechanic to understand them. The era produced many hackers.

Yes, like my my dad who built half of my parents’ house himself. And he is a piano teacher! Such were the times.

Fast-forward a quarter century, and the landscape is unrecognizable. Cars have so much electronics in their innards you can’t even replace your headlights yourself. Many don’t even know how to open their car’s hood, and if something breaks, it gets tossed away, not repaired.

If somebody was hibernated for a generation and just woke up, he could think we’ve gotten comfortable and lazy. But these advances in technology we’ve witnessed haven’t suppressed our imagination and curiosity: they have empowered it. You don’t repair your car because somebody else can do it better and cheaper, but you can put a Linux embedded system (carputer) in it and hack the traffic lights when you are in a real hurry (OK, I got carried away… but just a little).

Things we buy and use in everyday life (cellphones, coffee makers) are so potent we can devise other uses for them than the producer intended. And it doesn’t matter if the producer is OK with it or not: Apple’s iPhones is reportedly running its first Hello World! app. Apple shipped a dumb, closed-source device and the fashionistas will use it as such, but sure enough somebody will be running Apache on it very soon.

This poses a challenge to companies who have been used to having control over the things they put on the market. They can’t know for sure if their business model won’t be changed - hacked - from the outside. Which makes inviting, not discouraging, your customers to participate the only sensible approach.

Sphere: Related Content

July 30, 2007 | Filed Under CRM | Leave a Comment 

To Quit or Not?

Seth Godin has a gift, a very American one I might add, of storytelling that makes holding his books and turning the pages a joy. Such is The Dip, a brief etude on when to quit (and when not to): a literary dessert.

It has 80-something pages but could easily be condensed to just one:

  1. Be #1 at whatever you are doing.
  2. To get there, you will, after the initial outburst of energy, get to a point where you will need to sacrifice your whole self to cross the line that separates masters from has-beens
  3. You have to know if you’ve got what it takes; if not, quit, and don’t be ashamed of it.

Anybody could tell you that, yet it’s one thing to absorb a bulleted list and another to give it 2 hours of reading and pondering. I suppose this is what separates true writers from people who have an opinion and can write; I, for one, can’t get myself to spend any more time on an idea I have already covered here, which could explain both the scarcity of content lately and the lack of continuity… but I digress.

The Dip is a motivational book, and I recommend reading it whenever you feel like giving up and going with the flow, not sticking your head high, taking the easy way. Time is the scarcest of resources, and it doesn’t make sense wasting it on being just 60% good, 40% happy, or 55% motivated.

Sphere: Related Content

July 11, 2007 | Filed Under Asides & Off-topic, Enterpreneurship, Me & You, But Mostly Me | Leave a Comment 

iPhone, I don’t love you

THE IPHONE HASN’T ARRIVED IN EUROPE yet, but it doesn’t feel that way. A week or so ago, I had to repeatedly hit “Mark all as read” in Google Reader to get rid of gazillions of posts that had “iPhone” as their subject matter. Tiresome.

I do appreciate Apple’s genius in creating fanboys. There’s engineering skill and design inspiration in all their products that’s easy to like. That said, Apple may be one of the last proud members of the Old Skool of marketing: the company knows best. Damn, the “smartphone” doesn’t even come with an SDK! Shouldn’t Apple, by default, give us the taste of their own dogfood?

Yes, iPhone is “cool”, mostly as a fashion / lifestyle item; perhaps Apple should label it as such and nobody would gripe that it’s a black box device with little “hackability” potential. Armani doesn’t provide source code to his suits either.

But we living in Geekdom want our source code with everything, don’t we?

With cellphones, it was first about using it as it came, then came J2ME and smartphones that brought new possibilities and choices, but the manufacturer was still in charge. This can now change.

Having written about my ideal “hacker’s smartphone” before, I was happy to realize that FIC is shipping its opemoko-based dev kits as of today. Sure, it won’t generate headlines a 1/1000th of the magniture that iPhone has. But revolutions don’t always announce themselves with gunshots and fireworks. This may, just may, be a beginning of a true democratization of the mobile phone market, just as Intel’s x86 processors have done for the personal computing market. It is based on the assumption that any assumption about the device’s use is inherently incomplete, that users will always come up with new needs that the manufacturer hasn’t even considered, and opens up platform access to any developer.

This is exciting, CRM 2.0-ish if you allow, and I’d love to see some community-marketing effort from FIC in the near future so that the promise of the concept can be verified and tested in the real world.

Technorati Tags: , , ,

Sphere: Related Content

July 9, 2007 | Filed Under CRM | Leave a Comment 

Requirements vs design

THERE ARE 2 TYPES OF PEOPLE WHO PROVIDE YOU WITH REQUIREMENTS:

The first group has a vague feeling about their need. You need to find the spot that itches and scratch it. They’ll expect you to know what they are thinking and won’t talk to you unless you are finishing their sentences and materializing their ideas on paper. They are easy to deal with when you’ve done your share of similar projects and can be their partner.

The other bunch is tricky. They may or may not know what they need but they sure as hell will tell you how you are supposed to do it. Example:

You walk into a meeting determined to (finally) get to the matter; if it takes interrogation of the 3rd degree, so be it. You’ve recently had a training of negotiation and other soft skills, so you are pretty confident you will, at the end of the day, know what they really want.

After a short chit-chat, they cover the table with Visio printouts and tell you where the buttons should be, what color, how will Systems X and Y integrate, how exceptions should be handled (the form will turn red and the user will click away a series of error messages…), et cetera.

Now, what’s a BA worth his name to do?

Talk about requirements, and you annoy them because they obviously know what they want and you are wasting their time. Concede the point and discuss their design, and you might end up with a solution that - surprise! - doesn’t serve their needs in the end. Why? Because their needs were so obvious they haven’t been tested.

Which brings me to my point. Business analyst is a natural partner and advocate of business needs and should fight for their fulfillment with both PM’s eager to slash the scope and developers who just want to do their thing. And as a good advocate, he has the right to extract and validate any information from his client that he needs to build his case. And damn well test it is since the opposing counsel will use whatever weakness he can find.

This isn’t about “translating” business requirements into technical specs, as the popular misconception about business analysis goes. Translating would mean taking whatever the client says and telling developers to build it. But if you do just that, you are wasting the oxygen in the room since developers could take such orders from business directly - who said they don’t speak plain English?

So - burn those Visio printouts. They stand in the way of understanding and obscure, not convey, what the needs are.

Sphere: Related Content

July 4, 2007 | Filed Under Software delivery | Leave a Comment 

Bratislava: Lessons Learned

I’VE COME HOME from a six-months long assignment in Bratislava, Slovakia, and while I am not at liberty to discuss project details, I’d like to share a few bits that I’ve learned there. It might be relevant to you out there who are also engaging in requirements engineering and/or software delivery in general.

And no, I haven’t accidentally re-discovered America: it’s been yet another experience in a series of many, and this just happens to be the first time I talk about it.

I’ll try to put out a short series on the software delivery process as I see it from the Business Analyst perspective; this installment will target some process-related issues and likely be updated as I think stuff through.

PART ONE: Process

A well-defined development process that doesn’t stand in the way of innovation and at the same time puts clearly defined limits on it is … a Holy Grail, and as such rarely achieved in a production environment. Nor is it often attempted.

In my capacity as BA, I mostly work in a documentation-heavy, top-down process context, and that’s when I am lucky: it’s not uncommon to work in a completely ad-hoc environment.

Worst of all, many clients will have rigid rules as to how they want things done without thinking through what they should want in the first place. The developer is then put in a position of very limited power without having been given clear clues as to what he’s supposed to accomplish.

As a result, the business analyst has no choice but to define the process himself and fight for its implementation with both the suits who are used to being able to push requirements into development at any stage, and the IT that is either defiant and unwilling to lift a finger or lethargic after losing way too many battles.

You could object and say it’s the PM’s role to worry about the process, to which I say: it can be, but look at the big picture: PM isn’t as concerned with requirements as he (usually) is with putting checkmarks next to tasks and walking importantly through the hallways. (some offense intended).

It’s my prelimiary conclusion, then, that the BA is most competent to define the process (from requirements to implementation) where there is none, since he has intimate understanding of what the suits want and what the developers are capable of delivering. Unlike the PM, he is also concerned with the value being created and delivered as he is personally invested in seeing it materialized.

Next: requirements versus design (tomorrow).

Technorati Tags: , , ,

Sphere: Related Content

July 2, 2007 | Filed Under Software delivery | Leave a Comment