currently interested in awesomeness and how to create it

Did Google actually arm its enemies with Android?

Interesting article over at HBR – it argues that since Android is open, manufactures might and indeed are sometimes replacing Google with other search providers in their handsets. As a result, “Google will not make a cent on this handset, despite having enabled its creation with Android. All the search revenue will flow to [other providers].”

Could be, but I think we have to consider the typical user approach to smartphone in general and Android in particular, which tends to be exploratory if not outright geeky. That’s very unlike Nokia use case (call & text) indeed.

So render me sceptical. In those markets where Google is the 500 pound gorilla, users WILL ask “Where is my Google?” and download / tweak their handset so that Google is back in play. Because in these markets, Google got there by delivering the best results, period. Users are not that “dumb” as when they simply used the defaults because going beyond defaults was going beyond pain.

Plus, there’s tons of other services (Mail, Maps…) which will continue to be present on these devices for as long as people use them, and through those channels Google will continue making advertising dollars.

I think Google’s main concern has been the oft-mentioned “fragmentation” caused by users having to wait for manufacturers to release OS updates. Once Google figures out how to deliver updates and upgrades with its own mechanism (Market or otherwise), they’re going to be just fine.

November 18, 2010 | Filed Under Mobile, Software | Comments Off 

Product and Project managers: different beasts?

Are product and project managers invariable at odds? Originally a question on whether a product manager can also function as a SCRUM master, the ensuing debate has brought a number of important points on the responsibilities of product and project managers in general.

I am going to re-position the debate in this way: can a product manager be so distanced from reality as to actually not be involved in the implementation at all? Commenter Jonathan puts it thusly:

I, personally, do not care about the software development process nor do I ask my product managers to. I expect my product team to focus entirely on value creation and when developing software is necessary to create value, others with that expertise can step in.

Specifically, Product Managers should focus on customer value, customer experience and where appropriate, assets collected as a result of product activity.

There’s definitely a lot of merit for this argument – if the product manager was “hands-on” involved in the technical aspects of the product creation, which he’ll never be as competent in as his software people, he would spend less time on actually envisioning and designing the product and making sure it fits market needs.

But, if the product is a piece of software, I believe that the product owner / manager cannot just draw it on a piece of paper without having a very intimate knowledge of how it’ll translate into an app or website code. And the role where he can oversee the development of his product could be the project manager role.

Of course, project managers are tactical beasts and their primary goal isn’t bringing a great product to market but rather bringing whatever was agreed on to market on time and budget, which can and often does mean haggling with product people over cutting features if one of these conditions, time or money, cannot be met.

Product managers hate cutting features. Hence it would seem impossible for one person to perform both roles with excellence without developing a serious mental disorder.

Then again, cutting features is as important as creating them, if not more, as the success of stripped-down web apps from Basecamp on has proved. The reality of software implementation and its constraints can be a strong motivator for prioritizing features and perfecting your specs to deliver those with the highest value while leaving the rest out.

In summary, I believe that product managers should try out the project manager role at least once to see what it really is like to bring something (web app, software, whatnot) out of nothing (specs and lots of sweat).

October 5, 2010 | Filed Under Software | Comments Off 

Don’t throw that mock-up away

Are “throw-away deliverables” such as requirements, mock-ups, or use cases a waste of effort? Yes, said Ryan Singer of 37 signals as he illustrated their design process at this year’s WebExpo conference in Prague.

Is such advice applicable to people who do not work at 37 signals?

If you’ve worked for a corporate client, you’ll know that on any given software project, more paperwork is generated than actual code. Paperwork that has no value on its own. Would it make sense, then, to go lean and go from sketch notes directly to HTML / code?

Remember, we’re not talking about a startup project. Your team has 20 members and 50 different stakeholders. Get them build the thing now, no specs, just communication and craftsmanship.

I’ll say that even with the best people money can buy you won’t deliver.

The value of “throw-away deliverables” becomes apparent when you realize people have trouble imagining software work. It’s near impossible to visualize a complete application in your head unless and until you have taken several intermediate steps – and created a number of throw-aways in the process.

These intermediate steps are (roughly in that order but not necessarily so):

  1. Business requirements and Use Cases (what the thing does)
  2. Wireframes, mock-ups (how it looks)
  3. Technical specs (how it’s going to be built)

Visit Scott Sehlhorst’s series on requirements for a detailed information on how good requirements make better projects. Suffice to say, if you don’t say what you want, chances are you will not get anything or you will get something else than what you want.

Even if you and your team can read your customer’s mind, however, requirements still have a tremendous value for the people who write them.

Say it’s you who’s writing them. It opens your mind as you explore the problem domain and forces you to focus and express yourself clearly. Instead of saying, make me an app that processes invoices, which is a very lazy way of putting it, you’ll think about each action that has to be performed for an invoices to be processed, and in that process discover many, many requirements that would otherwise have gone unsaid – and, therefore, un-implemented.

Mock-ups, and product visualizations in general, are complementary to written requirements in that they illustrate, verify, and complement them. Most people are visual and a conceptual mock-up will let them think in terms of user interactions, instead of just objects and results. Graphic models alone can help create an app that does not just solve a customer’s problem but does it efficiently and perhaps with an added aesthetic flavor as well.

Then there’s the element of time.

For the sake of the argument, let’s stipulate your superb A team of ninjas and rock stars have read the customer’s mind and built a perfect app for your customer. A year passes by and you part ways with this customer. Then, a B team of ninjas steps in to continue your good work. Except, they are not telepaths and have nothing to go on except your source code. Your former customer has not documented their requirements and thrown those napkins away a long time ago.

Baaam! Good luck navigating this mess! (not that it’s your problem anymore but you could just as easily become a B team in another example)

As you see a well-produced set of ‘throw-away deliverables’ can help all parties involved in a software project. Yes, they are not valuable per se, just like a blueprint of your dream house isn’t. Now, would you try building it without it?

I will say that I envy 37s who can work this way. And there may be many other teams who are doing so, and maybe you can, too. The mundane, boring, and oft-criticized way of ‘getting there’ with a paper trail in your wake is, however, still the way for many more teams and projects and will continue to be for as long as making software is a hard, unpredictable process with uncertain results.

September 27, 2010 | Filed Under General, Software | 2 Comments 

Requirements defined – the fun way

What’s the difference between an entrepreneur and a consultant?

No, this is not a lead-in to a joke.

Both get things done, but the entrepreneur has the ownership of the problem. The consultant can always walk away.

I’ve been in consulting long enough to know – and feel – the difference. Inasmuch as I love to solve other people’s problems, I’ve felt compelled to create some for myself; then solve them, for myself.

And so I did.

WHY

The #1 problem software project team face is not knowing what to do.The #2 problem is knowing it.

Communicating “what needs to be done” is hard. So hard that there are specialists (requirements analysts, business analysts, etc.) whose sole job is to translate information flowing between the so-called “stakeholders” (people with desires and money to satisfy them) and developers (designers, vendors, …) Even though they all speak the same language. Many times, the developer (and not just a software guy: in the broadest sense anyone who’s making stuff someone else desires) will either not know what the client wants or think he does but be utterly wrong.

No software or tool can make that effortless. Defining the product, the scope, the vision, or the requirements, all that will always be a human activity where tools can merely help.

Or, they can stand in the way, forcing their way of thinking and methodologies and “best practices” down everyone’s throat. Which has been the case with many “requirements management” systems out there.

And so I set out on a mission: to help people get the right things done by creating and tracing their ideas the fun way, or at least the suck-free way, and doing so together so that everyone is in the loop.

WHAT

It wasn’t about building a better mousetrap.

There’s quite a lot of good-enough tools for “managing” the “software lifecycle” and such (throw in your favorite buzzword). I did not set out to compete with DOORS. Or with Basecamp, for that matter.

Instead, I’ve focused on the process of formulating and perfecting ideas, weeding out those that won’t make it in the sunlight, and deciding which ones will.

This usually happens on paper. And in email. And no matter what, it gets messy pretty quickly. Changes get lost, intentions forgotten or mis-shapen, and even when there’s a nice Word document at the end, the time-span between handing it over to the developers and testing out a live product tends to be so long that those ideas that you want to help come true change many, many times (and not just because the world keep spinning – you do, too).

Keeping track of shit and knowing when shit changes is crucial to getting shit done.

And so I’ve begun to think and prototype a tool that would help me and you along the way.

HOW

I am just starting out. That’s after maybe a year working on it. Sounds pretty ridiculous considering the startups that put the shit out after a 72-hour sprint. But hey, it’s a one-man attempt at world domination. And that takes time.

The website has been out for about 4-5 months. The app started looking barely-good-enough about 2 months ago. At this point I’m re-thinking most of it, and making it a real business in the process. Just learned the LLC that’s behind it is – finally! – established and in Good Standing  in the state of New Hampshire, US of fucking A.

What’s next?

Next, I must come out. It’s not an easy thing to do, and this post is one of the first things I’m doing to do that.

I am putting myself out there to re-think and re-define and pro-mote the way people gather and perfect ideas and make them happen. Not an easy task but as Hugh McLeod said in his Microsoft cartoon, “Change the world or go home.” How’s that for raising the bar, eh?

If you’ve gotten this far, the problem I’ve described sounds familiar to you and you’re probably looking for a solution to it. Well then, why don’t you go ahead and test-drive Playground, the application that I’ve made, so that you know if the solution I am proposing is one that could help you?

It is my intention to do this the right way, the customer-driven way. I am working with people who are trying Playground out to make sure that they can define, plan, and implement the ideas they have in a effective (and not just efficient) way.

Let me know what you think.

February 25, 2009 | Filed Under Enterpreneurship, Me & You, But Mostly Me, Software | 3 Comments 

Panic not quite deserved

Salesforce.com was down for ~40 minutes, and the airwaves are full of “what does this mean for the SaaS market” reflections again.

40 minutes?

Just 40 minutes?

It’s a testament to the ever-increasing capabilities of on-demand vendors that we’re talking minutes not hours or days. And if you’ve ever been a client of a “traditional” software vendor (regardless of respectability), you can certainly appreciate it. You are probably paying top dollar for 99.9% uptime, which translates to roughly 7 hours of downtime a year.

Fact: software systems fail. Sometimes they recover without the user noticing it, sometimes they crash hard. The rates of failure are different in mission-critical systems (airplanes, nuclear power plants) and other domains (both enterprise and consumer). But they all fail sometimes.

We would have to see a systemic failure to start questioning the viability of the affected platform, and since Salesforce.com is not the only SaaS platform out there, I can’t imagine what would have to happen to drive happy customers back to the on-premise cut-throats.

PS … “In fairness, Salesforce.com’s uptime record is still the envy of many IT and business decision-makers” – same column as the one mentioned above.

January 11, 2009 | Filed Under CRM, Software | 1 Comment 

Apple’s way isn’t the only way

Dare Obasanjo made an excellent argument about user experience and the open ecosystem can fail when it doesn’t deliver that. It was particularly painful for me to read and acknowledge. Openness is a virtue but virtue alone doesn’t make a viable business model.

Developers go where the users are. Users go where they can get the best user experience for the right price. Openness of the platform only helps if it improves the user experience, thus attracting more users and reinforcing the virtuous cycle.

He then goes on and compares the Windows Mobile way of installing software versus the iPhone way. Needless to say, Windows gets quite a beating.

As someone who has recently had his WinMo smartphone go nuts to a point it had to be re-flashed, I am not blinds to the faults of the platform. Neither am I turning my head away from the unfulfilled promises of the Linux-based handsets. It’s bad.

Is the Apple model worth following, then? Should Google play their game with Android?

I believe not. Though mobile phones are not PCs (and Windows Mobile fails most when it makes you think differently), they are not iPods either. They fall somewhere in between. So it’s OK if they are married to laptops for the purpose of installing software and/or maintenance – as long as the guy manning the laptop doesn’t have to do much thinking.

It’s the platform’s jobs to make that marriage a success. Everything else can be left to developers. And they will come if that experience makes sense. If Android or any other platform can start making sense, I don’t see why it wouldn’t attract its share of hearts and minds.

September 29, 2008 | Filed Under Mobile, Software | Comments Off 

Del.icio.us back in Web 1.0

Delicious.com?

Mis-spelled and “dotted” domain names have become the mandatory feature of Web 2.0 sites. I’d venture to say Del.icio.us was, if not the first one, then certainly in the first wave of companies of this sort.

Delicious.com?

Not only the domain name but also screwed-up user experience has pushed the new release of the social bookmarking site back into Web 1.0 world where its parent, Yahoo, resides.

Let me qualify that: the very first contact I had with the new release was when I chose to sign-in from the del.icio.us Firefox extension. It led to a Yahoo page saying I wasn’t authorized to access that page.

Unauthorized to log in?

I hope that once I get in, I’ll find a reason or two not to churn.

Damn.

July 31, 2008 | Filed Under Rants, Software | Comments Off 

Doc Searls on VRM

Doc Searls explaining VRM to a Telco crowd at Mobile Monday in Netherlands:

Worth watching. CRM 2.0 and VRM aren’t neither synonymous nor adversarial but complementary, and I am glad to see that both camps are finally coming together.

June 14, 2008 | Filed Under CRM, Me & You, But Mostly Me, Software | Comments Off 

The Coolness Factor

Firing up your office laptop, logging into SAP and screaming WOW: no, this doesn’t happen. Enterprise software is boring, and quite frankly I cannot understand where does the whole bunch of Enterprise Irregulars find the temerity to tell Scoble he was wrong to wonder, Why enterprise software isn’t sexy , and say he doesn’t get it. There is nothing to get, folks: enterprise software is boring, boring, boring, 99 percent of the time, and no, it doesn’t have to be; methinks Workday looks pretty cool (judging from the demos), and so does Salesforce.

And you know what? It’s not a coincidence I’ve picked up these two. SaaS is a disruptor in many ways, and one of them is getting rid of the internal IT and all its silly policies, long implementation times, and the inevitable hordes of consultants. It has to appeal to users.

But I digress. Enterprise Software is so horribly soulless and user-unfriendly due to a number of reasons:

  1. Purchasing decisions are made by paper-pushers. End users are usually not involved as they are “represented” by a somebody who hasn’t been at the frontline for a long time, won’t be using the software, and therefore doesn’t really know what it should do and how.
  2. Internal IT - too much work, too little appreciation = not much motivation. Group them with a “team” of hastily assembled junior Superheroes from Accenture, and boy, you’ve got no time for sexy; you are happy if the code compiles and does just barely enough so that you can move on to the next release.
  3. There is never enough time and money do to things right. Enterprises have a huge number of priorities they need to juggle, and making their employees happy isn’t nearly as important as making them productive (as if these two weren’t interconnected), and by productive the suits usually mean an insane screen with lots of grids and forms generated from database tables (100+ attributes to handle), so that the poor schmuck doesn’t have to navigate anywhere, he’s got everything “at his fingertips”, and he does and they bleed at the end of the day, but who cares.

Here I stumbled onto the answer: the Enterprise doesn’t usually look at its employees with the same CRM-fueled passion as it does at its customers. They are, after all, a column in the Expenses section. So why bother? They cannot switch to a competitor’s application should they dislike what they’ve been served. Damn, they can seldom change their desktop background; the cubicle slavery doesn’t allow for neither software choice nor simple self-expression.

I believe this is changing; SaaS is playing a huge role in it, and so are all the gadgets we buy that free our mind and scratch many itches. As we move from the purely utilitarian to the beautiful (compare the first CD players with PS3), the workplace is going to change, too, and so is enterprise software. In its own clumsy, passive-aggresive, uninspiring way.

PS For a sober look at the subject, read Jason Fried’s post on Why Enterprise Software Sucks.

PS II: I concur with Nicholas Carr:

By perpetuating a false dichotomy between the friendliness of consumer apps and the seriousness of business apps, all that Krigsman is doing is giving enterprise vendors cover for continuing to produce software that’s difficult and unpleasant to use. Give Scoble credit. He’s asking the right question, in his own strange way.

December 10, 2007 | Filed Under CRM, Rants, Software | Comments Off 

Agile analysis, waterfall delivery

ITERATIONS, SCHMITERATIONS… Many a developer shop claim they are using an agile (as in RUP, not XP) approach, yet when time comes for them to put money where their mouth is, they are doing the ol’ good Waterfall.

Part of the problem is – the Customer. The Customer wants to know, up-front, what the application will look like.

But – although there is some truth to the old saying that all software would work perfectly if it weren’t for the users – blaming the customer is rarely a sound business tactics.

Why would the customer need to know exactly if he could trust the vendor implicitly?

Yes, trust. So many failed projects on their books, few companies have faith in vendors’ competence. They put provisions and clauses in the contracts so that they can sense an impending catastrophe before it strikes. One of these clauses: the Analysis shall deliver a complete specification of the final product.

Poor analysts.

They become designers, software architects, and documentation makers. Rarely do they have time to spend on their favorite subject, Requirements. Meaning the requirements rarely make it into the design, which leads to a product not matching the client’s needs, which leads to … poor satisfaction and a little less faith, again.

Here’s a solution: think agile, and the Waterfall can work.

Some deception is needed. The analyst will create beautiful visual representations of the final product – be it UML diagrams, a GUI prototype, or web page demos. And he has to work the client to make him think this is, indeed, the product. It has to be logical and detailed and, yes, sexy. The analyst has to seduce the client so that he sees the final product even though he’s actually looking at an abstraction. One that is decidedly incomplete and open to changes.

Indeed, visual modeling is a great way to capture, verify, and test requirements.

I understand the Agile camp looks at diagrams with certain disdain. Truth is, diagrams have no value in themselves – the client needs the code (or function thereof) – BUT they have a tremendous power in that they suck the customer in. He has something to look at, to dream about. And in that process he can express his wishes better than through written word.

Of course, the visuals don’t tell the whole truth; they do, however, define a boundary for any requirements that can and will come later. Which can allow for some agile approach even though the process goes from Analysis to Design to Development etc. and doesn’t allow for requirements to be formally introduced once Analysis has finished.

The product will never look exactly the same as the specs produced by analysts. It might, however, be closer to the customer’s needs, and even if the customer notices the differences, I doubt he’ll complain.

September 26, 2007 | Filed Under Software | Comments Off 

Next Page »