Posts
I have been hearing a
lot of talk and questions from my peers about apps. What they love and what they
hate, but mostly what they wonder... There is always a question of why... Why don't you have this, why does this do that, why does this import, why doesn't
that export... In my opinion, many of these whys aren't really whys at all,
they are When's. What we really want to know is when will it do this, when
will that fixed, when can I use this app the way I want too? Basically,
we suck at explaining ourselves to developers. I was given some great
opportunities to speak with developers at multiple companies this week. Aside from being able to communicate my ideas to them, I was able to learn how
they need to receive information I order for it to have any value to their
teams.
They don't know what
you're saying because it doesn't make sense.
Draw a picture,
compare a competitor, remind them that you don't speak their language. I am
constantly reminding developers that I have no idea what they have to do on the
back end to make my dream come true, and encourage them to re-direct my
thoughts according to technical feasibility. Most of the time when we are
trying to explain something we are looking at it from a 1-client view or an 'I
want' perspective. The most effective way to validate your suggestion is to
prove that your 'want' adds value not just to you, but to the platform as a
whole. Paint them a picture not just of the what, but also of the why. The how is up to them.
We give input without implementation experience.
Many times we turn
away from a product due to the 'feature lack' that we see in a demo. We may not
implement that product because of one little thing that is missing, therefore our
only experience is the demo. Once we have made the decision NOT to try a
product, we need to accept that since we have absolutely no working experience
with the program, we have no place discrediting it's application. For
example I wanted to integrate Lettuce for a client but I needed a more robust
sales tax module, so I only demoed it. I know of some other industries it would
be great in and I would apply it in a heart beat. The fact that I
implemented Vend instead of Lettuce does not make Vend a better app, it makes
it a better app for that client. We need to quit pretending like every
industry should have a shoe box solution and work on becoming educated
ecosystem engineers.
When you divorce a
vendor, forget the no contact order.
I'm sure ALL of us
have had bad experiences with apps... Spending hours fixing things that we
can't bill for because it was our dumb@$$ that suggested the implementation. I
have divorced many an app (I even took a year off from QBO once), but we need to remember to be civil. You are much better off leaving
amicably so that you can keep yourself educated on any new things that may put that app ahead. We need to forgive developers of their past mistakes so
that we can take advantage of their future triumphs.
Fool me once, shame
on you. Fool me twice, shame on me.
When I demo a product
I usually go in super excited about where I want to use it and the clients
that I'll put on it. By the end of the demo I generally have a huge
paradigm shift and realize that it is not what I thought it was at all. If they
fool you once with their sales rep, email, or misleading advertisement, then
shame on them for not being clear. I always look at this thankfully with a
'crisis-averted' attitude and throw the app in my toolbox for future use. Now
if you choose to implement the product anyway because it's pretty or cheap or whatever,
and it turns out not be the right fit, that is YOUR OWN fault. If you have
demoed a product thoroughly and asked
all of the right questions then there should be nothing that they told you
that you did not verify before implementation. Test Test Test!! It is up to you
to be the expert.
What's your opinion? Feel free to post, tweet or email your thoughts on the matter.
No comments:
Post a Comment