4 minute read
Reputation is critical. As they say it takes years to build and moments to destroy.
This is made harder with data projects because often the consumers of our data products are not technical experts.
They can be unsure about what is possible and have little idea what goes into their creation.
The result is that they can be an unforgiving audience that poses a high risk to your reputation.
“What I’m after is something like …”
They can also be quite unclear about what they want.
Unspecific about what they need.
Some almost half-expecting you to “just know” what to do, like you can jump inside their heads and read their minds.
Sadly the consequences of this situation are often well meaning projects that simply don’t deliver.
Disappointed users reflect badly on you. So how can you avoid this?
The reason, in my experience, is normally always rooted in a mismatch of expectations; often set (innocently) right at the projects beginning during the eagerness to get going.
What we are aiming for (as creators) is to deliver tools and reports that really work for the user.
That help them get just what they need.
To enable them to really benefit from what technology has offer them.
Feels great to succeed
Personally, that feeling of accomplishment when someone you’ve been working with tells you what you’ve put together is “perfect” is so good.
Maybe it is just me but making a positive difference to someones (work) life is so rewarding.
To have worked through and solved their issues. To have produced a tool or report that will transform their ability to do their work, AND, be appreciated for it … wow … it is really the best IMHO.
The carrot for me is that feeling.
The stick of course, is the (constant) worry about not having understood things right.
To be putting your heart and sole into the wrong solution.
To be risking the gutting feeling of their disappointment.
The guilt that they’ve wasted their time and money with you.
The terrifying risk of an associated long term reputation of failure.
How to avoid project failure
Luckily, through some painful trial and error, I’ve developed a method that delivers me that win, more often that not.
If you’ve ever found yourself in a situation where you’re at a loss in terms of dealing with a tricky user perhaps this will help you next time.
Aim to serve.
It is firstly about mindset. Specifically getting yourself in the frame of mind that you are there to serve.
I’ve worked in many technical areas and with countless “engineering” types. One mistake I see more than ever is belittling the customer in some way.
The premise is that the product does what they want and the fact they can’t work it out is their problem.
Makes me twitch.
If they don’t understand it, then you have failed. Not them.
The goal is to build something that they can use. That offers value to them. That they are going to love.
Nothing else really matters to a projects success.
Think: Beauty is the in the eye of the beholder.
It is ok to be humble.
Take responsibility for the brief
By definition, they are going to struggle to be able to articulate exactly what they really want or what success looks like.
I know others disagree (some strongly) about this but my experience tells me that it is 110% our responsibility, as product creators, to help them determine what success looks like.
We should help them work out what it is that will actually add value. To roll back from the tech and determine the fundamentals of what they are looking to change and why.
Interestingly, I also find, invariably that the tech we choose to employ can be more interesting and more creative. But that is a nice by-product for the geek in me.
The pure goal is to better understand the needs and requirements of your users, and, get them totally bought into it as soon as possible.
You’re helping them out to be honest.
Get on the same side of the table and work through it with them.
To get a bit more specific, let me introduce this concept of the three knows.
A tail of 3 knows.
The three knows are “I don’t”, “I think I” and “I do.”
In my experience, most people start at “I think I know” and carry on from there.
Stop yourself. Roll back. Assume nothing. Really.
Sometimes this is easier than others, especially if you’ve no domain knowledge.
For example, I remember first walking into the GB Disability Shooting team.
We can all understand the basic rules of the game (shooting at fixed targets) but really, what does it take to win a Paralympic Gold medal in that sport?
I have some idea now but really there was no shame in saying I had no idea at the time.
They had to explain it to me.
They actually found this quite challenging as I really didn’t know anything about their sport.
I had to clarify everything they were saying to me.
I’m recommending you try the same and get who ever is your customer to keep explaining to you what it is that will make a difference so you can really start to know.
Genuinely start from “I don’t” know.
What you want to do is start from “I don’t know” and get your users to tell you.
And keep telling you.
Throughout the whole project (really!)
The one issue here is of confidence.
So as a technical expert, it might be considered that you should know what you’re doing. That you shouldn’t ask “silly” questions.
This is true but the issue isn’t around technology it is around your understanding.
The better you understand, the better the outcome for them.
Tell them that.
If they make a request, mirror it back to them as a question and get their confirmation you understood correctly.
It is about finding out what success look like – for them!
Trying to determine, without any shadow of doubt, their specific, unique situation and their subsequent requirements for improvement.
Apply the tools you know (but to continue learning)
Use what you’ve got at your disposal to help continue to learn what success looks like.
The underlying premise is that you never really know until the project finishes.
At the early stages of a project, feel confident to ask clarifying questions.
You might even sketch.
As you get into the project, if it is a report or dashboard, mock this up.
Go to your user and say “if this worked, is that what you want?”
Build simple proof-of-concepts that they can try out.
Watching them using them and note were they are getting stuck.
Ask what they are trying to achieve.
Everything you create is your interpretation.
Put everything into your creations but expect them to be “wrong” in some way.
Iterate to improve your understanding (and your product).
These activities are I’m sure familiar.
The subtle difference is in their application as a method for learning.
All the time you’re constantly confirming, to you and your user, that are on the same page.
Projects are a learning journey from “I don’t” to “I do” know.
Remember the goal is to build something that works for them.
Think of your development project as a learning journey that takes you from “I don’t know”, through “I think I know” and all the way to “I do know” – normally right at the very end.
If you can pull that off, even if it is not what you’d like personally, then that is project success.
I’ve learnt this the hard way over the years. Put this into action and hopefully you don’t have to.