Adopting Something New

New technology can be a little daunting, especially when you are no longer going greenfield and have to move an existing application to a new platform.

But it can be so exciting, so much to learn, so much to understand, so much to try out.

And then we pick up the old system and dump it onto the new platform, not changing a thing, leaving it as it were and moving on.

We pat ourselves on the back fro “Adopting Something New”.

Really all we have accomplished is to take a lawnmower engine and put it into a Ferrari and called it a Ferrari.

New Technology Adoption isn’t easy, it’s fraught with pitfalls and failure.  But when we simply put what’s old into something that’s new, it isn’t an upgrade, it isn’t a new release, it isn’t even a service pack – it’s a copy.

Inconsistent User Design

Over the past week, I’ve had two experiences with applications implemented across a variety of platforms with completely different User Experiences – I can hold one up against the other and see the difference.

Different features, different access points, etc, etc.

Even worse, I can look at these experiences across a variety of devices and platforms and see how they are completely different in their implementation as well.

If you are building a solution across a variety of platforms and devices always remember;

  • Consistency is key – don’t limit the user to their device/platform of choice, enable it.
  • Feature parity is Paramount – If you are building all mobile, great, but then we know the back-end services are all the same, so keep it on par from device to device.
  • It’s All On – don’t implement some on, some off functionality because you haven’t finished the feature, hold off on deployment until it can all be on, by making it an inconsistent on/off you are simply inviting negative feedback from users.

Nothing turns a user off more than thinking your application is amazing only to have to stop using it because it doesn’t work here and there when it states it should.

Eliminate those distracting issues so you can get to the core of what users want and start building valuable add-ons for them.

Software Built on Trust

Or Trusted Software is the best kind of software.

It’s built on a foundation of teams and groups working together to accomplish an insurmountable task that no one ever thought could be done.

I have witnessed this happen so many times – and when it does – all I want to do is sit back and watch, because it is amazing.

Requirement Guys, Cloud Girls, Server Boys, Coder Girls, Database Dudes, Super Dudettes – it’s a symphony of development.

Built on trusting one another, trusting the people, trusting the method and trusting the outcome – supporting the failure and celebrating the success.

The best kind of software there is.

 

Give them the Demo they Need, not the One that they Want

Ask anyone what their problem is and they will tell you exactly how they want to solve it and make it go away.

I could easily come up with a few of my own problems and solutions to them, but their wrong. It’s not that I don’t trust myself,

It’s not that I don’t trust myself, it’s that they are framed by own view as to how I perceive the problem. In that frame, whether I want to accept it or not, I have already inferred a number of assumptions important to me, but perhaps not relevant to the problem at hand – either based on my own perceptions, personal

In that frame, whether I want to accept it or not, I have already inferred a number of assumptions important to me, but perhaps not relevant to the problem at hand – either based on my own perceptions, personal decision-making framework, and/or environment.

That’s why when working with a customer, it’s important to dig deep to understand the problem they are trying to solve before suggesting solutions and platforms that could fix their problem.

Customers don’t always want to hear this because they “know best” for the very same reason that I know the answers to all of my own problems – by the framework and worldview that surrounds me. Sure there will always be some aspects of alignment but it’s important to not take this at face value.

So how do you get a customer to buy into seeing the demo they need?

  1. Show them what they believe their problem to be, get them to agree to what has been discussed with their team during a requirements session.
  2. Show them what their problem really is and watch.

Did you get it right? Did you get it wrong?

Perhaps – but did you start the conversation to go deeper?

That’s the goal.

In the end, it’s about starting that conversation of what they need vs what they think they want and moving forward to solve the real problem.

And it’s not solely for customers either – take the word customer and replace it with “team”, “colleague”, “project”, etc.

Accepting the Solution is the easy part

Understanding the solution…
Learning the solution…
Breaking the solution…

That’s the hard part, because now it’s more than blanket acceptance, now it’s learning, growing, questioning, evolving.

The worst answer in a newly implemented solution when it breaks.

“I don’t know, I never looked into it”

Don’t accept the solution, break it down, figure it out, own it, make it yours.

Only then should you deploy it.