Skip to Content

There is a reason Mark Cuban is a gajillionaire

Mark Cuban is, as far as I can tell, living the dream.

He owns an NBA team. He has money. He is (and this hurts to admit) taller than I am. And he gets to say whatever he wants. And a lot of the things he says make sense. Especially when he says that you shouldn’t always listen to your customers.

We, as IT folks, have customers called “users.” Users are very often smart dedicated people who power the company and make sure it is able to afford us IT folks. Sure, we like to give them a hard time with ticket resolutions of PEBKAC and logged ID-10-T errors, but generally speaking they try hard (and they really do pay our salaries, which is important). But they one thing they often can’t do is ask for things in a truly out-of-the-box way. And that is where we need to help them help themselves.

Requirements gathering can be awful. It can be really, truly, terribly awful for those of us who are analysts types, and even worse for developers who also happen to wear an analyst hat. All too often we either build the users the interface they want (but not the one they truly need) or we build one that does neither (often due to a developer or analyst who thinks they know what the user needs and fails to listen to them). The first (letting users design their own interface) is no good because they just don’t know what to ask for or what is possible. The second (building them something with no input) is no good because we in IT don’t listen, build them something they can’t use, then get mad at them for not using it.

With dashboarding and mobile solutions cropping up, it’s more important than ever we partner with users to design the interfaces they need. A 60 year old accountant knows a ton about accounting, but probably not about designing a mobile workflow for submitting expenses. The developer knows the shortcuts to build in, what the best practices for design are, and how to deploy it, but they won’t know what the reporting requirements are, how to map expenses to accounts, etc. You need both bodies of knowledge to be successful.

In my experience, in order to be successful you need to have both pieces. You need the developers and analysts to really, REALLY listen to what the users need, and the users need to trust the developers and analysts to remain true to the spirit of the requirements but have a little wiggle room to make the GUI work out thoughtfully. IT’s job is to serve the business, but the business has to let IT do what it does best. Xcelsius design is a perfect example of this paradigm. Users come to IT asking for a report, but we need to build them an application and really change the way they consume information. Users can tell you what data points they want to track, but right out of the gate they can’t tell you the optimal button clicks they need to get there.

In the end, Mark was right that you can’t have users driving the vision, but — at least in a corporate environment — you do need them driving the requirements.

And, if he had held onto Steve Nash he’d have been VERY right.

You must be Logged on to comment or reply to a post.
  • At a previous job we would do “follow me homes” with small business owners. Instead of sitting them in front of a computer and saying “what would you like this software to do for you?”, we would just watch them go about their daily jobs, trying to accomplish specific tasks in their natural environment (submitting invoices, doing payroll, etc). Then we would go back to see if we could make those tasks easier and more productive. So the users were (in theory at least) giving us implicit requirements without being constrained by any preconcieved notion of what software could or could not do.

    This example may not be as applicable to dashboarding and mobile solutions, but I thought I would share it in the spirit of conversation :-).

    You bring up some great points, and btw I’m also a Mark Cuban fan. You know he could bring back Nash this offseason too 🙂

    • Thanks for everyone’s replies so far (I was out of pocket for a few days and couldn’t respond). Love the follow me home ideas, and the prototyping (thanks, Michelle!). I think having the user and the developer concentrating on adding business value is a big first step.
  • We’ve taken to doing “proto-types”.  Very little real processing behind the covers, but enough to demonstrate the technology.

    Once the proto-type phase is done, we get the real requirements.

    And of course our requirements are never done until the project is complete.

    It doesn’t always work.  Re-work is my middle name sometimes.


  • Hi Jamie,

    Couldn’t have agreed more on this where its all technical topics that floats across but equally important are the ‘soft’ aspects which leads to a successful implementation for both the ‘user’ and the ‘consultant’.

    Had written on a similar topic, would appreciate some thoughts on these please.

    Feasibility Study for SAP BW Implementation –
    Feasibility Study for SAP BI/BW Implementation

    Requirement Gathering process for SAP BW Implementation –

    Kunal Gandhi