Welcome to Pragmatic. It's all part of the plan.
Pragmatic is a weekly discussion show contemplating the practical application of technology.
Exploring the real world trade-offs, we look at how great ideas are transformed into products and services that can change our lives.
is as simple as it seems. This episode is sponsored by Harvest. Harvest lets you time your tasks
wherever you might be doing them and easily analyze your time sheet to track billable or non-billable
hours and turn those into invoices for your clients with both PayPal and Stripe integration.
Check out Harvest at getharvest or oneword.com and sign up for a free 30-day trial and start
tracking your time and invoicing others simply and painlessly. Once your 30-day trial is up,
Use the coupon code 'Pragmatic' at checkout and you'll receive up to 50% off your first
month. But hurry, because this offer expires on the 15th of January 2015.
This episode is also sponsored by Mandrill. Mandrill is a transactional email service
that easily ties into your website and apps when you need to send one-off emails like responses,
password resets, acknowledgments and so on. Visit mandrill.com and sign up today. Why not?
it's free and use the promo code pragmatic to get 50,000 free email transactions per month for six
months. Normally there's only 12,000 a month, that's four times the normal amount. Integrate,
deliver, track and analyze using email infrastructure from Mandrel. We'll talk more about them during
the show. I'm your host John Tidgey and I'm joined today by my guest host Seth Clifford. How you doing
Seth? I'm doing well John, thanks for having me back. Oh no worries, thank you for coming back.
Before we dive into today's topic, I just want to quickly do a little bit of pre-show blurb.
It's now possible to see the list of topics I'll be covering on the show in coming weeks and months
at techdistortion.com/topics. If you're not a member, you will be able to see the list,
but if you sign up, you'll be able to vote on the existing list and also suggest whatever topic
you'd like covered on the show. I'll be locking in episodes a week or two ahead of time and people
can see the topic and co-host or guest host ahead of time so they can tune in and know what to
to expect. Go check them out. I've also started releasing an equivalent to the After Dark/After
Show/B-Side thingies, whatever you want to call them. I'm calling it Adenda. It's at
techdistortion.com/podcasts/adenda. So go check it out. It's also on iTunes. You can
always search for it in there as well. And finally, if you're enjoying the show and you
haven't yet rated in iTunes, feel free to do so. Always appreciate it. Always very much
much appreciated. I've also changed servers recently and put a new VPS up that's now located
in San Francisco so it should be a little bit zippier than before and it'll clean out
all the cruft and it's all nice and squeaky. Brand spanking virtually new because it's
virtual. Anyway, there you go. That wasn't very funny. Never mind that. Okay, so this
This is a bit of an interesting topic that you want to talk about, Seth, and it has to
do a lot with how design is, shall we say, I'd like to say guided, but it's not so much
guided.
It's more a little bit bullied and a little bit shoved around by different interests,
shall we say, like, well, there's marketing and advertising and obviously the customer
as well, but I thought it might be interesting to sort of look at how we focus when we're
being pushed around by all the different competing demands when we're trying to deliver something.
What do you reckon?
Yeah, I think there's probably plenty to talk about there.
It's one of those things that we had kind of chatted about prior to the show, you know,
several weeks back.
And I think it's the kind of thing that depending on where you work and with whom you work,
you either have a great handle on this
or you struggle with it or you're constantly battling it.
And there's a very,
there's a tough line you need to draw
as a person working in a creative field
when other people are actually paying you directly for it,
but also influencing your creativity.
And you have to kind of compartmentalize
how you feel about that to perform at your highest level.
So I think there's probably a lot of interesting directions we can go with.
Okay, well I think where I'd like to start is I'd like to start by thinking about how
we divide this up.
So when you're developing a product and I guess the design is for either, we could classify
it as either for a single individual or an entity.
And when I say like an entity, it's like a truly, honestly,
single point of authority.
So I guess that's sort of the way I differentiate
because you can still develop something for an entity
that has one overriding voice.
Whereas you can also have an organizational customer
such that you have five, six, seven, eight different people
that you're trying to satisfy.
So I think there's a bit of a difference
between like sole customers and organizational customer
sort of affects a little bit about how you go about pleasing who you please. Sort of
just might help in sort of breaking this down a little bit. Also I think it's worthwhile
breaking down the design being for internal or external organizations and I may sound
a little bit you know douchey but I mean honestly if you're developing something in-house for
your own internal needs you know which you know we've both sort of done but a lot of
the work that we've done predominantly has been for external organizations and when you're
doing things in-house, you can sort of bend rules and change the way you can change your
direction a lot more with a lot more agility and a little bit more free will there. Whereas
if you've got an external customer, it's a very different story, it becomes more of a
negotiation. So I think that's worthy of breaking down as well. I don't know, I guess you could
break it down further in terms of if there's money involved, but that's probably beyond
the scope of this really. So, okay, I'm thinking about a matrix like a quadrant. I don't mean
like a matrix where you plug a thing in the back of your head. I mean like a 2x2 matrix
whereby you can look at elements of a design as being in terms of their implementation
as being straightforward or complex. And I realize that that's a simplification, but
I mean, let's just say that there's something that some other party wants. It doesn't matter
if it's the customer or if it's someone who wants something from a marketing perspective
and say, "Oh, this would be a really marketable feature.
We got to have this."
Irrespective of what kind of feature it is, it could be either straightforward or it could
be complex.
I guess my point is that that would be one axis.
On the other axis of the matrix, we could say, "Well, something could be a completely
independent feature."
In other words, it doesn't affect any of the other features in any way.
It's very, very isolated.
It has its own little, it can build in its own little style.
It doesn't affect anything else.
Or it could be very interdependent such that if we add this feature, it's going to
affect one or more other features of this product.
So if you think of it like a matrix, this is the way I want to sort of try and tease
this out a bit, is the four quadrants of that matrix kind of do the whole
straightforward and independent, which is totally easy.
Someone says to you, hey, you know, we want to add this.
It's really straightforward feature
and it's completely not gonna affect the rest of the product.
It's like, you know, snap your fingers.
Yep, okay, no problem, that's easy.
But when things get a little bit more complicated
when you say, okay, well, maybe a straightforward feature
but now it's interdependent.
So in that second quadrant, it's like, okay, well,
now we need to consider
all of the different interdependencies.
We don't wanna affect like, yes, okay, the customers,
the marketing guys say it's gotta be blue
'cause blue is pleasing to the eye.
Who was the company that did all the studies
about the different shades of blue?
Was that Microsoft or Google?
Someone did.
- Oh, I don't even remember.
I think it's one of those two.
- Yeah, I think it was.
And they came up with blue being the most pleasing color
and therefore it was a predominant background color
in one of their wallpapers or something, but anyway.
So there's that.
And then there's the complex and independent
in that third quadrant
where you got something that problem is very,
it's complicated to implement,
might take a fair bit of time.
And that comes back to cost, schedule, prioritization.
And you could put a person to hack away at that
for a long time and see what they get as a result.
But because it's independent, they can sort of do that on their own.
And that's that. And then finally, the fourth quadrant where everyone is angry.
And that is if it's complicated and it has a lot of interdependencies.
And it's like, OK, now what do I do?
And usually those are the ones we end up having to say no, because it's like, well,
you know, we've got a fixed budget, we've got a fixed amount of time.
It's too complicated and there's too many dependencies.
I'm sorry, but we just can't accommodate that.
Oh, I don't know.
What do you think?
I think that's as good a place to start as any. I think that probably encapsulates most
of the kinds of decisions we're talking about.
All right, cool. I guess the thing is the easiest position you can take as a design
lead is to say, "I'm going to take the uncompromising position." I'm going to say, "You know what?
If as lead designer, I don't want it or it's not in the contract, it's not happening."
Now that's the easy way anyone can say, you know, it's not in the contract
I don't care, you know, but the problem with that if you want to take that path
You just you're not gonna have very many happy customers. You just not you're not gonna get repeat business
You're not gonna get a good reputation. Yeah, and it's easy, but it's not
It's it's easy for you on paper, but it becomes less easy for you sustain, you know to sustain that kind of behavior going forward
Yeah, exactly. And it'll hurt you in the long term.
So, the reality is I've worked with organizations like that
and there are some aspects of the organization that I may or may not currently be involved with
that'll have some of those aspects in common, in certain areas only.
But yeah, it's frustrating as hell because you realize that, you know,
no one's doing themselves favors by taking an uncompromising attitude like that.
So, not recommending that for a second.
But I guess the thing is, I also, I see the flip side of that.
And the flip side is, I want you to develop a product for me.
And I have to give you an idea of what I want.
But I can't design it all and think it through all up front.
I can't put every single requirement down on a piece of paper
such that we have a complete map from start to finish of everything that I want you to create for me.
for me because it's only happening in your head and you're limited by your own head.
You're limited by the space in your brain. There's only so much you can think through
and therefore there's only so much you can write down at the time of writing a contract
and say, "Well, here's kind of what we want. This is what we want as an end result," sort
of. But I can't tell you all of the little details and this is when things get tricky
because in that uncompromising position, you know, you can sort of say, well, you know,
this is a gray area now. It's like, well, you said you're going to give us, I don't
know, messaging or something as part of the feature set in the app. And what we'll know
that wasn't, it didn't explicitly say that it was or wasn't in. So I'm going to count
that as scope creep and I'm not going to help you. So I guess the point is that you need
to be able to tweak the design a little bit in some small ways as you go along and whether
or not you... you know what I mean when I say scope creep?
Yeah, I'm familiar with scope creep.
I actually think that I did pick that up in North America because I worked in North America
for a while and there's my buzzword bingo.
But the point is, yes, I think scope creep is one of those things that's a bit misunderstood.
So rather than me jabber on about it, how would you describe scope creep?
Scope creep is this phenomenon that occurs when you may, you know, let's assume you have
business requirements for the thing that you're trying to build.
And the business requirements encompass, you know, these five areas.
But the five areas may not be as well defined as they probably should be.
Or there might be aspects to elements of those areas that aren't as well defined as they
should be.
building the product, you know, let's say for argument's sake, let's say it's the contact
page on a website. And in the first meeting you say, "Well, what do you want on this page?"
And they say, "We just need people to get in touch with us." And you say, "Okay, well
then we're going to -- this will be a static page and we'll put up some information and
people will see, you know, an email contact and a phone number and your address and that's
And everybody goes, "Okay, great."
And we move on to the next thing.
And you build that page and you start doing other things and somewhere down the line,
the client looks at it and goes, "We were kind of thinking that maybe we should have
Google Map integration."
And you're like, "Okay, so how important is that to you?"
And they say, "Well, it's pretty important just because our office is really hard to
find."
and you go, "Okay, well, we think we have time in the schedule for that,"
or you say, "Well, we absolutely don't have time in the schedule for that,"
but if you say you think you do, then you either...
The smart thing to do is say, "Okay, we're adding this.
We need to reevaluate how this impacts the other stuff that we've already,
you know, committed to," but you add it and everybody's happy,
and you go, "Okay, we, you know, we accommodated them.
They're happy. That's not such a big deal."
And then a week later, somebody goes,
you know, we had another meeting about this.
And what we would actually like is
this proprietary kind of Street View thing.
We actually have a partnership with a company
that does this kind of thing with Street View.
But I think they have an API.
And you're like, OK, well, now we're
talking about far more than the static content
we had initially agreed on and more than the Google Maps
integration that we talked about last week, and it just becomes this kind of thing where
people keep meeting and talking and what they actually thought they wanted may be there,
but it's not quite what's the topic of discussion that week, and so you end up taking a static
HTML page that was supposed to be text and putting all these kinds of things in it.
And that's like a super stupidly simple example, but it's the kind of thing that starts out
simple and continues to balloon. In a lot of cases you have a really complex
feature that is very well documented and somebody says, "It would really be great
if it did this one other thing." And you're like, "Well, it would be great but
unfortunately that one other thing means two more weeks of engineering and another
week of QA." And you know, it could be anything that's added to the project
along the way that swells both the overhead involved in project management
development, design, QA, and then finally, you know, how long it takes to deliver
that feature. And it happens all the time and it's one of the toughest things to
deal with in a client service industry because you want them to be happy and
you want to please them. But to do your best work you need to be very mindful of
when that is happening and you need to be very forthright in describing what's
happening to them and letting them understand that we recognize what you're doing, we hear
what you're saying, we want this to be a thing that you can have, but you can't have it now.
We can phase it in later, we can talk about when it is an appropriate time to add this.
Or if you really must have this, then we're going to compromise and find something else
in the project that isn't as important now that we can drop and use the time for that.
So it's that kind of scenario that we usually face.
Okay, cool.
So when...
And I have had similar experiences in different contexts as well, and I think that's a pretty
good definition of scope creep.
I guess the way I would say it is scope creep is new functionality beyond the original scope
such that if it was omitted, as in not implemented,
then the product would still meet
the original design intention.
And so if it falls inside that category,
that you can consider that to be scope creep.
And I guess when you,
this is more of a more curious question than anything else,
is when you do quote,
when you quote for a job or factor your rates,
Do you include an allowance for, I hate to say scope creep in that context,
but miscellaneous general and say, well, you know what, we can handle
maybe a week or two of additional tweaking here and there as a buffer.
And then once that's gone, it's gone.
And because I have to admit, I'll put my hand up and say,
I've actually have done that on some fixed price quotes.
I've actually gone and said, you know what, I've got a buffer here of X number of weeks
of engineering hours to account for,
like for example, if I've got a vague spec
that I'm quoting to, I will put in a lot more time
because I know that there's gonna be creep
beyond what is in the spec.
Is that something that you have come across?
- Generally speaking, we try to plan
as accurately as possible.
We don't really buffer things like that
because we've gotten to a point,
thankfully, where we are very, very tuned in to the, the
conversations up front and getting the documentation that
we need and nailing everything down. And so we plan specifically
to the features that need to be built. And certainly sometimes
things take longer, and that's, that's a different issue. But we
don't really like add time in that way, because we do a lot
more upfront research on what we think it will take
to do this feature, that feature, this other feature,
and then also to test those things
and make sure that they're all functioning properly
so that we can have those conversations later
and say, we are on time, we're on schedule.
These are things that we've agreed to build.
We want to accommodate you,
but we either need to move things around in the schedule
or we need to push the date, or we need to do,
you know, like you have those levers
that you can push with clients and say,
if you've got a date that's immovable,
then we need to have a conversation about,
you know, what is important and what isn't important
to ship by that date.
If your date is flexible,
then we can have another discussion
about adding other things in.
But I think it's important,
I think it's important to not have
too much of that wiggle room
because it forces you to be extremely focused
on what needs to get done and in what timeframe.
And as you do this more,
you learn to have those conversations earlier with clients
and you learn to be as clear in your language as possible
because when you don't adequately describe to them
how this is affecting the overall product and project,
then they're not gonna understand it.
Like that's for you to explain to them.
So I think a lot of people do build in that kind of time
just to allot for that.
And there's nothing wrong with that.
It's not, it's, I wouldn't label that as like,
you know, some kind of weird nefarious behavior
because you understand what is being asked of you.
And if your business requirements are flexing
or they don't know what they want,
you may just have a conversation with them and say,
"Look, I'm gonna say it's gonna take this much time
"because we don't know what you guys want yet."
I think that's perfectly acceptable too, but it's all part of having those conversations
early and in clear language so everybody's on the same page.
One of the other approaches that they take in my specific line of work is they will do
a… well, sometimes people will refer to as a budget price.
So they'll have a very brief framework of a specification and it'll go out to market
and they'll say, you know, you come back with a budget quote and the budget quote will have a very wide percentage on it.
So it'd be like, you know, plus or minus 35, plus or minus, you know, 20%, whatever.
And you put in that value with a median expected value and, you know, a positive, like an over under on it.
And, you know, then they'll do a shortlist from there, develop the design a little bit further,
and then go back and say, right now we want your fixed price quote.
I mean, that's fixed price quoting and in engineering,
like in construction industry,
which is a very different industry from developing software.
But even so, I think, as you say,
I think it is a valid approach to do that,
but you have to be very careful
that you don't look like you're putting in
way, way too much buffer.
Otherwise, first of all, you won't be competitive.
And second of all, if they ever see the cost breakdown,
'cause half the time they want to see a cost breakdown
of your hours, even if it's in part,
is it's difficult to hide that.
And a lot of customers will come back and say, well, hang on a minute.
What's this big miscellaneous thing for ten million dollars?
I don't I don't agree with that.
So, you know, but then, of course, then you're up against the battle of, well,
do you break down your costs or do you not?
And, you know, I've I've had different managers who have said, well,
you know, you should if they ask for it, then we should.
And other ones have said flat out, no, they get one price.
We don't break down our prices. We don't care.
and if you're hungry for the work and you're up and competing against others,
we'll break it down and you'll be breaking it down whether you want to or not.
Anyway, yes.
So I guess rather than go on
too much more about that, I'll just actually very quickly
talk about our first sponsor before we get into the next section, and that's Harvest.
Now, many people listening to this show spend their time
working on home projects and work projects, too, and you lose track of time.
We've talked about this on the show previously, about being realistic,
about how much time you have available to you.
Now, one way you can track your time is by using Harvest.
And they have a simple to use web app
where you can create tasks.
They also have mobile apps for both Android and iOS.
It's easy to select the task or an activity,
start and stop a timer from any of them.
On the Mac, it installs as a neat menu bar icon
that detects when you've been idle for a long time.
When you come back, you can then choose to deduct
those idle minutes or hours from the total.
Yeah, it's little touches like that.
Very cool.
Anyway, it's a great way to track where your time is going.
And after you're done, it's really easy to look back
at your time sheet to see where the time's gone.
That's handy enough, but if you're working on a project
with a team, your coworkers can track their time,
and it makes it really easy to manage everyone's time
on a project as well.
So Harvest also makes invoicing easy.
And it's quick and painless to set up clients
and multiple points of contact those clients
if you have that, and build invoices using that information.
Very, very quick once you've built
once you've set it all up.
Better than that, Harvest lets you pull your hourly rates
and your time sheets to create those invoices
based on those rates,
integrates nicely with PayPal and Stripe.
Now I've been using Harvest invoices
for the podcast recently,
and it's now taken over as my invoicing system of choice.
I think it's really nice.
Check out Harvest at getharvestalloneword.com
and sign up for a free 30-day trial
and start tracking your time
and invoicing others simply and painlessly.
There's no credit card required, no obligation.
They just want you to see how great
and how handy it can be. There's no excuse not to give them a try. Now, once your 30-day
trial is over and you've realized how great Harvest is, use the coupon code "Pragmatic"
at the checkout and you'll also save 50% off your first month and that applies to any
of their plans. Hurry though because this offer expires on January the 15th, 2015. Thank
you once again to Harvest for sponsoring Pragmatic.
Okay, so where were we? I was thinking about...
Okay, so I want to talk a little bit about the difference between marketable features and core features.
And I guess the reason I think this is important is that...
I don't know. I get the feeling a lot of people don't appreciate enough of the difference
and some people look at it as an either/or and it really isn't. It's simply two different
sets and the sets can overlap and that's perfectly fine. So the way I see it is and I'd like
to hear your take as well, but my take is a core features you have to have otherwise
you just do not have a product that you can sell or hand over.
Whereas marketable features,
you know,
marketable features essentially are designed more to drive sales and they sound
great, but they don't necessarily have to be core features.
And the issue comes,
ideally you want to develop where they overlap.
You want to develop the marketable features that are also core features,
because if you're spending time working on too many core features that are not
obviously marketable or don't appear to add much value
to the product, then it becomes less,
less, well, less marketable.
You're spending your time on that solid foundation stuff.
And that's a dangerous game to play in some respects
because if you start saying,
well, I'm gonna whittle away my core functions
'cause they're not marketable,
well, at the same time, you gotta balance that with,
I've gotta have my core functionality,
otherwise it will not be saleable at all.
So it's really more the other side of that
where the, not the overlap, not the core features,
but the marketable stuff that's just there
for marketable reasons, for marketing reasons
and sales purposes, and it's not really a core feature,
it's not really a huge deal,
or it only addresses a very small subset of potential users,
spending a lot of time and effort on those
is perhaps, I would suggest, not ideal.
What are your thoughts?
- I would agree with that.
I think that probably when determining
what's a core feature and what's a marketable feature,
it comes down to what the initial idea is.
Like what are we setting out to build?
Is it the kind of thing that only a subset of a subset
of a specific demographic would be interested in?
Well, then maybe we shouldn't even be building it
because the effort that we're gonna be putting into it
isn't probably worth even marketing
to this smaller population.
But in more specific terms of
how do you balance those things,
yeah, sometimes marketable features are your core features.
And I think when you have that scenario
where your core features are the most appealing
to the people that you want to have using your product,
that's the optimal scenario
because you can spend all of your time
building the things that people are going to love about it
and the things that you're going to want to talk about.
But regular people, consumers,
even just users in an enterprise setting
don't really care, most of them don't really care about
the engine that drives the product that they're using.
So your core features, if you have a giant backend
that needs to serve all this data and do all this stuff,
it's one of those things where you're never gonna be able
to really talk about that.
So you have to understand what that product does
and potentially reframe what it's doing
to provide value to the people that you're trying to reach.
And you may not have marketable features,
but you need to create a marketable message
so that people understand the value
of what you're trying to bring to them.
And that I think comes down to, again, the initial idea,
plus the people that are charged
with understanding the product and delivering that message.
A lot of times, the people who are building something
are all very kind of heads down.
And you may have a lot of engineers, a lot of developers,
and project managers, and people like that.
But nobody's really thinking about what the end goal is.
They're just trying to deliver a set of code on time.
And that's fine, and that's very noble,
because that's how business is done.
But that still needs to exist after that delivery date.
And if that product doesn't thrive,
then you have to wonder why it was even undertaken
in the first place.
So there is a balance to be struck,
but I think it really has a lot more to do
with understanding the core of, to reuse that term,
the core of what you're building,
and then not even building features to appeal to people,
but building a story to appeal to people,
because you can take a really boring product
and have it appeal to people if you show them
and you demonstrate the value.
Absolutely, that's a good point.
One of the things that I also found
as a difference between a product that is,
and I guess this is the problem,
I don't want to say successful versus not successful because that's not,
that really is quite a simplification and not really the point of what I'm
getting at.
It's more a product that is efficiently
created from, from inception to delivery.
And those are the products that are focused.
And I know that I think, you know,
we may have talked about this previously
or I have on the show, but the, and focus is,
it's very, very important because what I've come across
on products that tend to fracture a bit
and they tend to develop too many of these features
that are called marketable features
that aren't core features and stuff.
People just, someone in the group,
in the team has a great idea.
And they're like, you know, this would be great
if we did this.
And rather than spending a week working
on the core features that they absolutely have to have
or on core features that are also marketable features
that the product should have
and satisfying all of the customer's requirements
but they'll go off on a tangent
and they'll develop this one section.
They'll say, you know what?
This is one feature, this is fantastic.
It'll become their pet feature.
And as a project manager or design lead
That's your worst nightmare.
Because it's like all of that creative energy and all of that talent is being
directed towards something that either was not sanctioned or not fully sanctioned
or not required or not part of the
plan. And I found that to be endlessly
frustrating. And it's like I thought to myself for the longest time, well, you know,
Is that a failing of minors in the project management role?
Am I simply not, you know, how do you manage that?
How do you balance that?
Because you don't want to put your foot
on the back of their neck and say,
you will only develop this.
There is no room for any of your personality,
any of your desires, wishes, wants, any of that stuff.
You know, you're a machine,
churn out code and stop complaining.
I guess if you're a professional and the longer you do it,
maybe that's more the case. But at the same time,
I've met a lot of, I guess maybe that's my problem is I've worked with a lot of
younger programmers that simply don't respond to that.
And they're in it because they enjoy it.
And if they don't have some degree of artistic flexibility and say, "Oh,
I really wanted to add this or this little thing, and it's a great idea.
And I'm sure the customer would like it.
And I swear it'll only take a few hours." Yeah, sure.
But anyway, is that just me or have you come across that?
No, that's, it's not just you.
Usually in what we do, we see it coming more from the client, right?
So you've got a project that you're working on for, you know, a large
corporation and you have your key stakeholders who all have a different
idea of what this thing is supposed to be or do, and there's usually one person
who has a little bit more pull than the other people, and so that person's
desires kind of bubble up a little bit more. And a lot of times, what you've committed
to build and the idea that you've presented and what that person wants are not fundamentally
opposed but they're on diverging paths. And you need to kind of delicately and professionally
bring those two paths together to converge again so that you can still deliver the product
that you want to build, but also satisfy that person's need to have their idea validated.
And the trick is, what you were saying is more an internal thing, like the young developer
who wants his amazing code gymnastics to shine through in the product, there's always going
to be that kind of thing that you need to contend with.
I think that that's a very different kind of condition
where as a manager, you need to understand
what that person, I mean, it's all psychological, right?
In both cases, it's understanding the psychology
of the decisions being made and reacting to them
in a way that is favorable for everybody involved.
So the business lead at the company
wants his idea in there so that he can trumpet it later
and everybody pats him on the back
and says, "What a great idea."
the young developer wants to show off
just what a great developer he or she is.
And they both need to be handled delicately
because you want the client to be happy
and you want your developer to be happy and productive,
but you need to understand the point
from which they're coming
and why they're saying the things they're saying,
why they're doing the things they're doing.
So in the case of the young developer,
you need to kind of convince them
that they can apply those same methods
and that same kind of thought process
to a part of the project that actually is important
and needs to be built to the detail
that they're thinking about it.
And for the business person,
you need to show them that,
hey, we hear your idea and we love it
And this is how we envision it being a part of the product.
And it's just kind of,
you have to kind of just guide them back
to where you need them to be.
And that's a very tough skill to learn
because as a project manager,
as somebody who's kind of driving a project,
you want everybody to be happy,
but your bottom line is that you need to deliver on time
and on budget.
So there's all these kind of tangents
that you need to manage.
And it's tough.
and you really need to be, you need to be flexible
because sometimes things do need to change,
but you also need to be as rigid as you can be
because everybody needs to understand
that we're all working to get to this point in the future.
And if we're constantly injecting our personal feelings
into this product, as opposed to what the business
has required, we're never gonna get there.
And there's gonna be gaps, and there's gonna be parts
that maybe look great but don't even work at all.
- Yeah, and I think you nailed it right there.
It's about limiting how much personality
gets between the programmer
and the job that they've got to do.
And I guess one of the great things
about having complete control over what you're doing,
like if you're developing your own product,
is that you short circuit that
because you can decide,
you can make those decisions yourself as to,
"Okay, yeah, well, we really want this, we really want,
I really want this, I really want that,
so I'm gonna adjust my own priorities."
The funny thing is, of course,
that's probably not a good reason to do it
if you really wanna be really self-critical
and honest and fair about it.
And I think you should probably,
if you're running your own projects,
you should run them as though you were trying
to convince other developers on your team
as to why you should be adding certain features.
So I think that that's a worthwhile exercise
because you should be justifying to yourself
why on earth you want to spend three days working on making a button look just right
when that doesn't make a heck of a lot of economic sense, let's say.
But anyway, rather than get into that, I guess one of the situations I came across with a
younger programmer who was trying to sort of flex their programming skills, and I'm
not sure if I've ever mentioned this one before, but the story goes that we were doing a SCADA
package for a sewage treatment plant. I've done quite a few of those. In sewage treatment
plant, there's a thing called an oxidation ditch. The oxidation ditch has aeration. The
aeration essentially forces oxygen into the bottom of the tank through fine bubble diffusers.
As those bubbles travel up through the tank, they get dissolved in the water. Not all of
them, of course, but just some of them. That raises the dissolved oxygen. The dissolved
oxygen feeds the bacteria, the bacteria convert the organic
matter, shall we say, into a sludge that then sinks to the
bottom. And that's then pumped out and treated further.
Anyway, rather than tell you how sewage treatment plants work,
the point is that the SCADA system had to indicate that
aeration was functioning.
So, this rather industrious young engineer thought they
would do some beautiful code gymnastics, as she called them,
which I think is a nice way of putting it, and make them world's most
perfect Skada bubbles you have ever seen.
And these things were absolutely beautiful to behold, because what they did is
they followed a random track between set limits and you could programmatically set
the limits so that in the in the X direction, the bubble would weave its way
from the bottom of the tank to the top as it did so, just as it does in real life,
because the pressure of the water changes the diameter of the bubble.
So as the bubble start at the bottom, they're smaller.
By the time they reach the top, when there's less water pressure on top,
the bubbles are much larger.
So, yes, the bubbles actually increased proportionally in size
as it traveled up the screen to mimic exactly the way bubbles would work
in a real oxidation ditch.
And finally, just as a little touch to show how extra clever he was,
when you turned on the actual aeration system,
the tank would have no bubbles in it.
But as you turned it on, a wave of bubbles would start at the bottom
and they would make their way up to the top and fill the tank as a continuous stream.
When you turned off the aeration, the bubbles would stop at the bottom,
but they would continue to float.
The ones that were on the screen would continue to float to the top of the screen,
to the top of the tank and then dissipate.
It was it was beautiful, I will admit it was beautiful.
It took him a week to program that.
So 40, call it 40 hours of programming.
Now, we didn't have 40 hours of programming to waste making bubbles, you know, right.
So as an object lesson, this is not me beating my chest saying, "Oh, geez, I'm so clever."
But it's like I spent, I think, 30 minutes, maybe an hour tops, doing my take on it with
probably one tenth of the lines of code.
No, they weren't really random tracks.
They were pseudo random.
No, they were not adjustable.
And no, they didn't actually dissipate once you turned off the oxidation.
But you know what?
To the untrained eye that didn't know
what they were looking at,
they still look pretty well the same.
And it took me, you know, a ridiculously small fraction
of the amount of time that it took this guy.
And the difference was I wasn't focusing
on mimicking exactly the way it is in real life.
'Cause I mean, if I really wanted to be really nitpicky
about it, I could have said, well, he didn't,
he didn't mimic the turbulence that's caused
'cause all those bubbles cause turbulence on the surface.
There was no turbulence in the graphic.
I mean, I could be really, really nitpicky about that, but the point of the illustration is
that was time that was wasted on a feature that no one asked for, no one really needed
and yes, it looked beautiful to the trained eye, but to the untrained eye, no one cared.
So, and that's what happens when you take a week off, folks.
Because when you come back to work and you realize, "What, have you been doing for a week? Oh, really?"
Sorry, that's just one of my horror stories. I don't know if you've got any horror stories, but that's one of mine.
I'm sure I've got plenty, but we've only got a limited time that we can talk today.
Okay, fair enough. Well then, and on that note, let's talk about our second sponsor for this episode, and that is Mandrill.
Now, Mandrill is a scalable, reliable, and secure email infrastructure service trusted by more than 300,000 customers worldwide.
Now I've been asked what is Mandrill because most people understand email newsletters showing
up in their inbox and a lot of them come from MailChimp.
So what's Mandrill?
Well Mandrill is essentially the foundation of MailChimp is built on and it's been broken
out into its own service for discrete emails rather than a big mailing list.
So think of them like transactions hence why I call it transactional email.
And that's actually how it started though.
In the two years leading up to 2012, Mandrill borrowed a bunch of MailChimp's best engineers,
they promised to give them back at some point, and working in isolation, their Skunkworks
project turned into Mandrill, which is now the largest email as a service platform on
the market with more than 300,000 active customers, of which I am one.
So let's say you run a site like Tech Distortion, for example, and you need to send feedback
form confirmation emails, Mandrill can do that.
Distortion uses StaticMeg as its CMS and runs RavenForms as a plugin. You just add the API
key for Mandrel and that's it. It just works straight away. There's a bunch of new features
on the site with voting and everything and that's all used as Mandrel as the email carrier
for that. I had been using standard PHP mailer but since I switched to Mandrel it's been
much easier to track and debug and frankly it performs better anyway. You can use Mandrel
to send automated one-to-one emails like password resets, welcome messages, confirmations,
customized newsletters if you want to. Mandrill is quick and easy to set up and it's very stable.
It's been made for developers by developers with extensive documentation, lots of different
integration possibilities through their excellent API and the service has very high delivery rates,
webhooks, analytics, they've got it all. Now, Mandrill's website has a well-organized interface.
It has flexible templates, custom tagging, and advanced tracking and reporting.
It's also the only email infrastructure service with a mobile app that lets you monitor delivery
and troubleshoot from wherever you might be when you're out and about.
So Mandrill is also very fast.
It's got servers like distributed all around the world and they can deliver your email
in milliseconds.
And I tied on tech distortion from form submission, the email shows up within a second of submission.
It's that quick.
Detailed delivery reports, advanced analytics, a nice friendly interface means that if you're
If you're in a larger organization, the entire team from development to marketing can monitor and evaluate the email performance easily without having to hassle you as a developer and that helps.
So, visit mandril.com and sign up today and you should because it's free. No credit card, no commitment, just sign up and use the promo code pragmatic to get 50,000 free email transactions per month for the first six months.
four times the normal amount you normally get.
Integrate, deliver, track and analyze
with email infrastructure from Mandrill.
Thank you once again to Mandrill for sponsoring Pragmatic.
Okay, so I think that the bottom line
and just something briefly,
you mentioned stakeholders before.
Every time someone mentions stakeholders,
I just wish someone would do like a Gary Larson
(laughs)
like a single frame where you've got four business guys in ties,
holding plates with stakes on them and say the key stakeholders were in
attendance. I can't draw. If I could draw, I would do it.
Yeah. It's one of those phrases. And I don't know,
being on this show with you seems to bring out like enterprise speak,
business mouth. Oh, sorry. No, it's okay. It's just cause we've been in those
scenarios so long. They're just, they're in there.
They don't come up in casual conversation,
but in the context of a discussion like this, they just kind of bubble up.
Yeah, that's it. It's hard to avoid.
I guess the problem with those sorts of business euphemisms is that once they
enter conversational speech in a business environment, when you're talking
about business, you can't help but have them creep in as well.
And the other thing is that, you know, a lot of these expressions have a good
solid basis. They didn't start out being, you know, really annoying
cliched phrases, they started actually being a good phrase with a good purpose.
It's just that because people overuse them and use them in the wrong context,
then that sort of watered down their usefulness.
And then suddenly it becomes,
the key stakeholder paradigm is shifting through cross-pollination or something.
I was like, Oh God, really?
I still have never heard parking lot though.
You haven't heard parking lot?
No. I've never come across that. When Casey said that one,
I was laughing because I can picture it being used in a meeting over and over and over again
But yeah, I don't think I've ever heard somebody use that
Maybe it's a regional thing, but I guess if you've heard it, I guess not
No, well, no, I mean, I haven't heard it in Australia, but I've heard it in North America
when I was in Calgary, Ottawa
I mean, I don't think it was a Nortel thing
I always figured it was a...
I figured it was a North American thing
Maybe it's a different regions in North America say it
But yeah, the two were rat hole and parking lot.
Rat hole, sure.
That's an easy one to come across.
Oh, sure. And yeah, but again, that's something that you don't hear in Australia.
That's definitely North American meeting expression.
So you'll be in the meeting and someone will go off topic and say, no, rat hole.
First time I heard that, I'm sitting in the meeting going, is it a what hole?
Who's a what? Huh? Had no idea what in hell that meant.
And then when someone said parking lot, I go, we'll just throw that
in the parking lot.
And I kid you not, the first time I heard the expression,
I looked out the window.
What?
Yeah, looking to find a car park.
- How about, I don't wanna get too off topic,
but how about let's table this?
Have you heard that?
- Yes, oh God, yes.
- Okay, 'cause that I think is what we hear
where we are more than parking lot.
It's, you know what, this is great,
let's table that for later.
Which I don't understand, let's table it?
We'll build a table out of it?
I don't know.
I guess it's just push it to the side or something.
We'll put an idea on the table, but doesn't that mean you're going to talk about it?
So, to me, yeah, I found that expression to be counterintuitive as well, actually, because
it sounds like if you're- Because if you're tabling emotion, doesn't that mean you're
suggesting emotion to be discussed?
I thought I would have thought.
I have no idea, but we could probably have a whole show about that.
God, do we have to?
Please, no.
They'll come for our heads if we do that.
Okay. So, yes.
So, yeah, go stakeholders.
Yay. Anyway. Ultimately, though.
Okay. So, I just want to circle back and I guess maybe then we should probably wrap
up. But honestly, it comes back to
identifying the solid core features and not being pulled too far astray by too many
marketing, solely marketing based features.
and I think that that's the key, identifying those and staying focused and that's the difficult
bit because bottom line is time is always against you.
No matter how you want to think about it, people will say, "Oh, well, it doesn't really
- " some products can drag on especially if it's something that you're developing yourself
for your own purposes.
But the truth is that if you really are objective about it, time is always going to be against
you because it's a competitive market.
You're not the only smart cookie out there.
You're not the only company out there.
If you don't produce something quickly enough, someone else can and will inevitably beat
you to it.
Especially when you're developing on platforms, platforms become more popular.
Back in the early days of iOS and the App Store, for example, there was much less competition
whereas now there's so many people developing for the platform, the platform's enormous,
it's very, very competitive.
You've got to use your time wisely and you can't just throw it away on a feature that
It sounds like it would be good for marketing purposes, but it's really not a core function.
You just can't afford to be sidetracked for any real significant period of time on stuff
that is not going to get you to the end of your contract, to the end deliverable, to
where you're trying to get to.
I think that too many people lose sight of that and they're like, "It'd be so great if
we could do this or that."
Yeah, but that takes time and time is money.
If time wasn't money, time is still a problem.
Time is always against you.
- Yeah, that time is the one resource I can't get more of.
And that is the thing that basically drives me
in all my decision-making is,
how long is it going to take me to do these things?
Should I do them?
Is it worth doing?
Not even in terms of projects, just in terms of life.
Like that's one of the things
that kind of guides my thought process
in every aspect of what I'm doing.
And you know, you attribute value to certain things,
and certainly in business, there are things that have
a very, you know, a very perceivable value.
But yeah, like you said, even if time wasn't money,
time means you're not doing other things.
There are other things you could be doing
that you're not doing because you're doing this.
And so ultimately, you need to weigh out
what that time should be allocated toward.
- Yeah, it's an interesting way that you express that
is that time is the one thing that you can't get more of.
And it got me thinking that's true
because you can go back to a customer with a variation
and say, "Hey, you wanna add this extra functionality,
that's a variation,
it's gonna be an extra this amount of dollars."
And usually if it's something I really want
and there's scope for that on their side
of the budgetary fence,
then you can get that budget far more easily
than you can say, "Oh, I need another few more weeks."
Yeah.
Watch their head explode when you say I need another month.
Yeah, yeah.
Their customer will come back if you say that.
So it's a good point.
So I guess if I had to summarize on a set of points and I guess
the first thing and maybe this is obvious, but I think you need to be very
clear exactly who your customer is because so many people come to you from
within the organization, from within the customer's organization, asking for
different features, core features, marketable features, doesn't matter.
You know, essentially pushing the design and directions, you know, that it perhaps
shouldn't go, driving that scope creep.
You know, you have to be clear who your customer actually is so that you can
identify which ones, frankly, that you can ignore.
And I think you need to be very clear in your feature classification.
So when something comes in, you classify those.
OK, well, that's definitely a core feature.
We absolutely must have that.
If you are clear up front, you know decisively which ones to focus on, that's huge.
I also think you need to be honest about how much effort is going to be required to implement a feature.
And I've talked about this on previous episodes.
The bottom line is there's the ability to predict how long something is going to take.
And there's the emotional aspect of being optimistic versus being realistic.
And that is something that is a learned skill.
and it's very hard to, you know, it's easy for me to say,
but it's hard as a skill to learn.
But being honest means trying to take as much
of the emotion out of it,
a match of the optimism out of it.
Look at past history, you know, track your history,
track how long it takes you to develop things,
to design things and use that as your basis
for your prediction and take the emotion out of it
and be as honest as you can.
And when it comes to those fourth quadrant activities,
the ones where I'm, those, my fourth quadrant thing,
I talked about earlier whereby it's a complex feature
and it's got a lot of interdependencies.
Be brutal in saying no to those fourth quadrant activities
because if you are not brutal, you will never get there
because inevitably you'll just chew up more and more time
and you will just never deliver.
Do you have any that you would add to that?
- No, I think that summarizes it pretty well.
It's tough because when you're when you're not building something for yourself, there's an innate desire
I think in most people to want to please
the the people for whom you're building and
That that comes very often in direct conflict with what they're asking you to do
So it's yeah, it's really
It's a it's a really it's a balance that needs to be struck between
Being very aware of what's being required of you, you know
You have one one one part of that you have one part of I want to do a good job
I want this to be successful
You have another part that is I know these people are gonna just keep adding things or keep changing things
And I need to put my foot down and say hey if you want it for this price by this date
It's got to be this and you can't keep you know
you can't keep changing things and have everything in flux.
And it takes a lot of time and it takes a lot of learning
and a lot of experience.
Usually, I don't know many people who are great
at doing all these things right out of college.
It takes a lot of time to get these skills
all in the right balance so that everybody's happy,
the product ships, and you feel like you maintained
directional control over, not directional control
in the sense that it's what you wanted,
but directional control in that you steered it to completion successfully.
Yeah, I agree. It's difficult. I don't think, it's definitely a skill that no one is born
with. It's something that you have to learn and unfortunately sometimes it's the painful,
it's a painful lesson learning exercise. I sometimes feel bad when I learn some of these
lessons and I learn them at a customer's expense. It's rough because you look back and you think,
"Well, if only I've done this differently, I could've saved this amount of time and this
amount of effort and we could've put that to support some more features that they would've
liked." But I suppose the good news is though, most of the clients that I've worked with
have been relatively understanding. So unless you come in and do something really, really
and you burn a ridiculous amount of time,
and they take exception to it.
That really hasn't happened very often.
Most clients are pretty understanding
and they wanna work with you
to get the best possible result.
So, but definitely something you have to learn,
no doubt about that.
- Yeah, I think, if you're approaching it the right way,
the relationship with the client,
you want it to be long-term in many cases.
And if you're coming from a place of real earnest desire
that you want them to succeed through your efforts,
I think people are generally more flexible
than most people would expect.
And even if, like you said,
you wish you had done things differently
or you could have saved money
and put it towards other features,
I think people will recognize,
good clients will recognize the effort that you made.
And if you do those things and have the best intentions,
I think the end product is usually good enough
to suit their needs.
Certainly in a lot of cases they know
it could have been a lot worse
because sometimes they've worked with groups in the past
and it has been a lot worse.
So your results that you think
might not have been that great could be exemplary to them.
And if it all goes off pretty well,
you can continue working with them hopefully
and maybe take those lessons
and build something better the next time,
which is, that's a great scenario to be in
where you have a good relationship with a client
And, you know, the future is bright because you both understand each other and what each
party wants and are willing to, you know, learn together.
Absolutely.
Well, we talked a lot about on this episode about working for clients, doing client work,
and I mean, obviously, that's the majority of what we've done in our careers, and that's
fine.
I guess something though that Nickelfish is been doing a little bit more of recently though
is some more of your own stuff. Could you talk a little bit about that before we wrap
up?
Yeah, absolutely. For a very long time, we've wanted to build our own products and it's
been the kind of thing where when you do client work, it's tough to find the time to build
your own stuff because the client work takes priority, it pays well, it pays your bills,
keeps the business going.
So we found ourselves in a position at the end of last year and at the beginning of this
year where we had a certain balance between client work and availability and we said,
"Now's the time to do it."
And so we decided to form a separate, smaller company, a separate brand that's affiliated
with our company, Nickelfish, called Derby.
What we intend for Derby to be is our product team.
We have a handful of ideas that we've been working through, but we are super excited
to be able to finally do this.
The only way we were able to do it was to actually take a couple of us and completely
cut off from client work altogether.
I haven't dealt with clients myself since February of this year, which is, you know,
the majority of the year has been spent building, you know, a new process and getting this thing
up and going and focusing on a single new product that we're going to be, you know,
releasing pretty soon.
And it's been a really interesting couple of months and it's been a huge change from,
all the stuff we talked about.
But just to kind of touch on something that you said earlier,
we had talked about if you're building your own products,
it would be in your best interest to be really focused on selling features
to yourself to make sure you're spending time in the right way.
That is something that we've really, really tried to do.
We've done an intense amount of thinking and planning,
planning and every decision that we make within the app
that we're working on, we talk about it and we make sure
that it's for the right reasons.
And the right reasons might be because we think it's
a saleable feature, because we think this is something
that is core to the experience that needs to be there
so that people understand it or enjoy it,
or this is a change to the code that needs to be there
to handle this, this or the other thing.
And we've approached it with the same rigor
that we approach the client work that we do.
And it's been a really great experience
because it has not been the kind of thing
that meanders all over the place.
We've been very targeted and very focused
in what we wanted to build and when we wanted to build it
and the timeframe in which we had to do it.
And so the real test for us is gonna be,
when we release it, how does this thing perform?
And of course, we're putting it out
into a really crowded market,
but we haven't spent an inordinate amount of time on it.
So we're kind of looking at it as a case study
that this is the first time we've done this process.
We've gone down this road and had these things
kind of all working together.
And it is such a different animal
from the client work that we've done
that even if it's not an amazing success,
which of course we all hope it is,
'cause why wouldn't you,
you know, there's a lot of learning that we did
along the way that I think will influence
the next project that we take on.
And, you know, it's, as I said,
it's so different from the stuff
that I've been used to doing for the past 10 years or so.
It's exciting, it's terrifying, it's invigorating.
It's all those things, but it's still work.
It's still the same kind of work,
just with a different focus.
But since we're the ones making the calls,
there's this extra added gravity as to,
is this the right thing?
Is this the wrong thing?
Does this even matter?
Will people even notice?
And it's been a very strange and wonderful experience.
- Yeah, well, it sounds like, I mean,
Since February, you just said, didn't you?
I mean, that's nearly a whole year now.
So, it's been, that's a lot of time and a lot of effort.
- Yeah, I mean, the first part of the year was,
a lot of my time was spent kind of like
tying up loose ends on client projects
that I was affiliated with,
and also getting the process for this new
kind of thing started,
because we'd never done an end-to-end product ourselves.
So, there was a whole lot of planning that we wanted to do,
and we wanted to build, I mean, it sounds super boring,
but like we wrote a lot of documentation for ourselves
to understand what it was that we were trying to do
because we didn't wanna just go,
we're gonna do this thing and yeah, sure.
So we built decision gates and product funnels
and all of this stuff and spent weeks and weeks
just figuring out how we wanted to figure things out.
And if that sounds like an incredible waste of time,
I would strongly disagree because I think the danger that a lot of individuals and a
lot of companies find themselves in is that you don't do enough thinking up front and
now you get to a point where you are three quarters of the way through a product and
you're not even sure what the direction of it is or what your plan is.
One of the things that's been great for us is that we've been very clear the entire path
as to what we were doing and how we wanted to accomplish it.
That in and of itself is extremely freeing because you're not worrying about those things.
You're worried about the things that matter.
You're worried about your code.
You're worried about your experience.
You're worried about all the stuff that you should be worried about, not why are we even
doing this.
And that it took a while to actually start building from prototype to real production
code.
Once we got there, we felt like, yeah, we've done all the things we needed to do to get here.
This isn't just kind of a fly by the seat of our pants thing.
We're really planning for this thing to be a long-term viable solution to this thing we want to do.
Cool. So, how much further is there to go before you've--?
Until it's all out there, I realize that you've done some pre-announcing.
- Yeah, yeah, we have, we're getting close,
we're getting close.
We're probably in the very last stages
of fixing some last little bugs
and things that we wanna tweak,
but we're probably gonna submit to the App Store pretty soon
and we don't have a date in mind yet,
but we'd like to kinda get it out
either the end of this month
or the very beginning of December,
just because we're not sure with app review time
how long it'll be and we probably don't wanna
release right around Thanksgiving
'cause there's all kinds of other stuff that happens.
So we're getting very close.
The website is up, you can see a little bit about the app
and I have started to kinda talk about it a little bit more
which was fun in and of itself
because it was like a super secret for so long.
But yeah, we're pretty close.
So you should be seeing it
within the next few weeks I'd say.
Fantastic. All right, cool. Can't wait.
Yeah. Very exciting. All right, well, we might wrap it up I think at that point.
Unless there's anything else you wanted to add?
No, I think I'm good.
All right, cool. Well, if you would like to talk more about this, you can reach me on Twitter at johnchidji.
If you'd like to send any feedback, please use the feedback form on the website.
That's where you'll also find the show notes for this episode under Podcasts Pragmatic.
If there are topics that you would like me to cover, you can suggest and vote on them
at techdistortion.com/topics once you sign up for a free account at techdistortion.com.
You can follow Pragmatic Show on Twitter to see show announcements and other miscellaneous
show-related stuff.
I'd like to thank my guest host, Seth Clifford, for coming back on the show.
What's the best way for people to get in touch with you, Seth?
That's probably Twitter.
I'm Seth Clifford on Twitter.
If you'd like to see the work that we do, you can visit nickelfish.com.
If you're interested in the new company and the new product, you can go to heyderby.com.
Fantastic.
I'd also personally like to thank Harvest for sponsoring Pragmatic.
If you want to track your time quickly and easily with the ability to quickly turn those
time sheets into invoices for your clients with built-in support for both PayPal and
Stripe, then Harvest has what you need.
Check out Harvest at getharvest or oneword.com and sign up for a free 30-day trial today.
Once your 30-day trial is over, use the coupon code "Pragmatic" at the checkout and you'll
also save 50% off your first month, but hurry because this offer expires on January 15,
2015. I'd also like to thank Mandrill for sponsoring this episode. If you're looking
to improve your site or app and need transactional email that's reliable, integrates easily,
and provides easy tracking and analysis, then Mandrill can help you. Visit mandrill.com
and sign up today. You should because it's free, no credit card, no commitment, just
sign up and use the promo code pragmatic to get 50,000 free email transactions per month
for the first six months.
That's four times the normal amount
that they would give you.
Integrate, deliver, track and analyze
email infrastructure from Android.
Well, thanks for listening everyone
and thank you again, Sam.
- Yeah, thanks for having me.
(upbeat music)
[MUSIC]
(upbeat music)
[Music]
Question from Vic in the chat room. It's also Vic's birthday. Happy birthday, Vic. And his question is, how do you know when it's time to ditch unreasonable clients? Or perhaps another way of expressing that he then says is, where do you draw the line?
Well, first of all, that's a very loaded question, ultimately saying that they're an unreasonable
client.
Maybe they're just a... how do you define unreasonable?
I guess clients that keep changing their minds, I would classify as unreasonable.
Beyond that, I don't think it's fair to call any client unreasonable.
I don't know.
What do you reckon, Seth?
We've only done it, I could count on one hand,
the number of times we've done it,
because in that kind of business,
you assume that you need to maintain
the client relationship, and that's your goal.
So, you know, it's funny, you said something earlier
about taking the hard line as a designer
and just saying, "This is the way it's gonna be,"
and that's not, and there's a lot of people
that I have seen online either write or talk about
or talk about this kind of thing
and taking this hard stance and being like,
I drive my clients and this is what I know best,
what they want, that's why they're coming to me.
And I have to wonder if what kind of business they have,
what kind of repeat business they have
and what the relationships are like,
or if that's really just kind of bluster
and when it comes down to sitting around a table
and hashing out ideas, if they're actually not as,
you know, domineering as they'd like you
to think that they are, because it's really,
like any other relationship, you have to work at it
and it's not gonna be ideal.
Almost no clients are ideal, so you have to understand
where they're coming from and try to address the needs
that they have, and if it's really making your life
miserable, I think there's plenty of opportunities
to have conversations, but in terms of kicking one
and just being like, we're not working together.
As I said, we've only done it a couple of times
in 10 plus years of business.
And it's been a scenario where the client
has been either abusive in no uncertain terms,
or we're looking at the project and saying,
this is going to be an abject failure
and it is due to this client's involvement.
This is not a healthy relationship for us to have.
And just the way you would examine the relationship
with a significant other and say,
"You know what, this is not good for us."
That's something you have to do sometimes.
And it's not a great conversation to have
as it isn't a great conversation to have
in a personal scenario, but it occasionally has to happen.
But it's usually something that has to happen
over a period of time.
And you really have to be sure that you wanna do it.
- Yeah, absolutely.
And I'm actually, when you were describing that,
I'm going back in my mind and thinking how many times
I've actually done that. And there were 2
customers that I can think of in 20 years
where we said, we will not do business with you
because you are difficult and usually difficult from the point of view of
non-payment. And the non-payment comes in multiple forms.
You know, the strictest and simplest way to think of it is
I've asked you, I've invoiced you for $2,000 you haven't paid a cent.
You know, that's the obvious one.
But no, I mean, in terms of we're going to continue to ask for more and more
features, but we're not going to pay you anything additional for that.
And we're going to withhold funds for stuff that you've already actually provided
on the basis that this other stuff you haven't given us.
And the contract law in in construction contracting
Australia is a little bit gray in that respect, whereby in some circumstances
an end customer can get away with demanding that you provide that
as a variation for additional works.
And if they if the end customer then does not pay you,
then you have rights to go and take them to court.
But then, of course, they start arguing about how much value it's worth.
And, you know, you end up doing the work at cost plus a minimum percentage
and it gets very messy contractually.
So it's easier for us to simply say, we're not going to work with you.
Thanks for playing. See you later.
you can have whatever work we've done and we don't expect to get paid.
We're just going to walk from the contract.
And, you know, there's always after a while doing that,
if you do a few times, you end up writing clauses like that into your standard terms
and conditions. So answering the question,
it doesn't happen often and it's not a decision you take lightly because it's not
just it doesn't just affect.
I think taking a decision like that does not just affect that one
client relationship, that can, if you're not careful and if you do it too often, I
think that can drive a market
perception of your organisation, that you are customer hostile and that will
affect your ability to win work.
Without a doubt.
Yeah.
And that is a dangerous situation.
You do not want that.
So I think it's a good question, but the reality is it doesn't happen very often.
[8-bit music]