02:36 - Estimates

12:09 - Roadmapping

18:12 - How to Sell It

23:06 - Roadmaps vs Estimates (Defined & Differences)

30:21 - Dealing with Conflict (Estimate Pain Points)

33:10 - Budget and Value 

39:43 - Mismatched Expectations (Communication Cont’d)

44:47 - Productized Services and Consulting

Picks

Eric's Sample Trail Map (Eric) 
Antifragile: Things That Gain from Disorder by Nassim Nicholas Taleb (Eric)
The Terrible Two by Mac Barnett (Reuven)
INBOX PAUSE (Jonathan)
CouldApp (Jonathan)
Traction: Get a Grip on Your Business by Gino Wickman (Chuck)
99Designs (Chuck)
Fiverr (Chuck)

 

Hey guys.

Hello! [Chuckles]

Hello?

Hello.

Hey everybody and welcome to episode 157 of the Freelancers’ Show. This week on our panel, we have Eric Davis.

Hello.

Reuven Lerner.

Hi everyone.

Jonathan Stark.

Hello.

I'm Charles Max Wood from DevChat.tv. One thing before we get started, I just want to remind everybody that I am putting together another remote conference. If you're into Ruby. Go to RubyRemoteConf.com and check it out. We should have the schedule up pretty quick here.

Anyway, this week, we have on the dock to talk about roadmapping and estimates; my favorite things ever. [Chuckles] Who suggested this anyway?

Might’ve been me.

As a general practice or for the show? [Chuckles]

Yeah. We should talk about that too. So roadmapping, this is where you etch in stone exactly when you're going to complete the task, right? [Crosstalk]

‘This is just an estimate’. ‘You said –!’ [Laughter] Right? Am I right?

‘This is just an estimate’ is an excellent way to basically turn your clients deaf temporarily.

Yup. I think the best that I've done is I've offered a range. ‘I think it’ll take between this many weeks and this many weeks, or this many months and this many months.' And then most of the time, since I keep handing a number with a hyphen in the middle, they get the point, and they're not upset until I go over the upper bound.

Right.

Oh, that’s what estimates should be. If you're lucky, they're an educated guess so you should tell your client or whoever you're giving it to what’s the lower bound, what’s the upper bound, and something I do – and we can get into in a little bit – is I also give a confidence. I’ll say I’m 95% sure it’s going to be in this range if it’s a good estimate or if I've been there before, or I’m 40% confident it’s going to be in this range if I haven’t done this before and there’s a lot of risk there – whatever.

I found those really help a client understand, ‘it’s going to be in here, it’s going to be outside of it, what’s something we should schedule up front, what’s something maybe we should prototype to bring the estimate a bit closer’, but it’s all about delivering information around what you're doing.

Yeah. I would give my clients a confidence score, but they won’t see it unless I come and wave it in their face when I miss the deadline. And I just don’t think that would work out well.

It might be different for different people. One client that I'm working with right now, they really brought up the confidence score, and they're like, ‘what can we do to make some of these things more confident?’ I’m like, ‘in this specific case; there's nothing we can do except for start coding on it or prototype it because it’s unknown unknowns. We don’t know how it’s going to integrate together’, but they saw that right away.

Huh. Maybe I’ll try it then.

Yeah. That’s interesting. I've never heard of that. I avoid the issue completely [chuckles] by not doing estimates.

You don’t tell your clients when you think you're going to complete the engagement or get the work done that you agreed to?

No.

But could it be, Jonathan, that you're not in the development business? [Crosstalk]

Yeah. It’s partly that, but even when I did development – and I still do some development – I won’t commit to a deadline because I’m not in control of the deadline, so how could I commit to it? It doesn’t make sense because I have to – virtually, always the client is the bottleneck with something like a web design project; they’ll go dark, they won’t get content back to you, they're unresponsive because they get busy with an event or something, and I just can’t .

I’ll say the most they’ll get out of me is one of two things. One is there's no way this will be done before 3 months, so they can, at least, have some scope and I’ll say, ‘if you respond to every email immediately and get all the content to me when I ask for it, we could maybe get this done in 3 months’, but I don’t have control of the deadline so I’d be lying to both of us if I gave you a date that it’s going to be done.

Mm-hm. I can identify with that. My current client – I did deliver on time, but I told him 12-15 weeks. They came back at week 14 and said, ‘you said you're going to be done this week.' I was, but there were 2 weeks in there where I was basically hammering things out with the hosting because they went with Amazon AWS, they hired this expert guy to set it all up, and then since I had no control or access, when it didn’t work, I had no way to figure out what was wrong [chuckles]. And it took us about two weeks to figure that out. And he’s acting like, ‘I should just know how AWS elastic beanstalk works’ which I had never used it before.

Anyway, yeah, it’s that kind of stuff, right? It’s like, ‘Look, this isn’t my fault and I would’ve hit the 12week estimate if that hadn’t happened.

Did the amount that they paid you increase because it took 15 instead of 12 weeks? [Crosstalk]

I initially gave my fixed bid and they came back and said, ‘yeah, we’re not comfortable doing a fixed bid’, and I said, ‘Ok. Well then we’re going to do weekly billing and we’re going to spread that weekly billing out across the 12 weeks. And if we go over it, then you're just going to pay more than I bid initially’. So it did. It cost them an extra 2 weeks’ worth of pay.

Yeah. So to your original question there – there are actually two questions there, which is ‘what are your clients say when you go past deadline’, I say I don’t give them deadlines or don’t commit to deadlines’, but doesn’t change what they pay. So I’ll guarantee that it’s going to cost –whatever – $50,000, it’s going to take at least 3 months, maybe it’ll take more depends on a million factors that are out of my control, but we’ll get it done – in both of our best interests – to get it done as soon as possible because then I can move on to new work and then you’ll have your stuff.

I totally agree. The weekly billing was basically a ‘well, if you're going to make me take the risk on you paying me regularly, then –’

Why would they against a fixed bid? Was it just too high?

I don’t know because they wind up paying that anyway.

Most companies prefer fixed bids. They know what their expenses are going to be. It should be preferable to them, I would think, unless it’s such a crazy high amount – not that you're not worth of the crazy high amount, Chuck, of course – but it could be that they believed that they’d get a better deal or that you were just – that they’d get a better deal for a bearable bid. I doubt it, but it’s possible.

Yeah. It could be in payment terms. If it’s x thousand or whatever a week versus 20, 30, 40000 up front and then another 20, 30, 40 at the end; it just might’ve been easier to stomach little payments over time.

It could be. I don’t know. But basically, the bid was 36,000 and I spread it out over 12 weeks – you can figure what the weekly rate was. And yeah they wind up paying for 2 or 3 extra weeks.

What I do is – I’ll get into it in a minute, but I created a document I called the Trail Map. In that, I say, ‘here’s the estimates for all the features, but when you assemble everything, there’s going to be integration, there's going to be bugs, there's going to be meetings, stuff like that’, and I actually – based on a project, I also say, ‘I recommend you had a 10%, 20%, 30%. For some of the clients, I can tell they're going to be very – you got to hold your hands, maybe a 50% buffer. I might say it’s going to take a week to do this feature but when you're at in a buffer, it might be, say, 6 days, 7 days of development.

Then I make it clear to them, ‘if you don’t want to do the buffer, that’s fine, but you're probably going to lean towards the higher and then we’re going to blow through our estimates because we don’t have that safety net’. And I actually make it up to the client what they want to do; give them all the data, give them all the options, let them make the decisions.

Yeah. That’s interesting.

Yeah. I take the same approach as far as estimates and roadmaps go. Yeah, I write down all the features, I figure about how long I think it’s going to take, and then I do exactly the same thing; I had a buffer on for how much longer I think it’s going to take to do all the integration stuff, work with the client, do the meetings, talk to their ops people – whatever else, and then that's more or less what I –.

If I’m not talking to them about value – and sometimes that’s hard, like with this client – they wanted something that looked like diamond material even though it wasn’t. Yeah, that’s how I came up with the bid for them.

See, mine is – it’s a transparent – I tell them, ‘here’s the buffer I would put on’ and I don’t actually include the buffer into the estimates and so that way, they can see it there because it’s a common [inaudible] move – make your estimate then double it and tell the client that double the numbers; your buffer is opaque; they don’t actually know that it’s there. I do it the other way around so that they can see that I’m buffering this because of whatever particular [inaudible] the project.

Oh, I see.

That is pretty – I’ve never heard of anybody doing that. That's pretty cool.

What kept telling people that you're adding a buffer?

No. In combination with the confidence level thing, that's pretty interesting.

Right. It’s basically – it’s exposing the client to the fact that software is – these projects are a noble in many ways but it’s giving them a better sense of what’s going on because when I say to people, ‘well, that could take between 2 weeks and 4 weeks’, it’s hard for them to get a handle on that. First of all, they tend to be optimistic and they’re like, ‘oh, that means 2 weeks’. Maybe 3, but 4 would be the upper limit. [Crosstalk] I’ve gotten better over the years where I’m like, ‘Ok, it’s not worth saying 2-4’. I’ll just say 4, or 4-5 or 4-6, and if I’m low, no one’s going to complain but if I’m high everyone will know.

I think there's a psychological problem with that that’s on the developer which is that the fish grows to fill the bowl. If you put it out in the open like Eric is drastically surfacing. I can’t imagine a client walking away from a meeting with Eric and being like, ‘Oh, we thought that this was the quote’ because it sounds like there's so much language and conversation around confidence level, and low and high end, and buffer, and all these stuff that he’s exposing them to a lot of – inviting them into the complexity of thinking about doing the estimate. It seems impossible for them to have – down the road, when something jumps up to bite them or the project – it seems totally impossible if you talk to the right people up front that they would forget all of that. Is that your experience, Eric?

Yeah. And for a bit of context, my roadmapping goes either of two ways. One it’s, ‘hey, this is an interesting project. We need to figure out – let’s start a weekly billing and figure out the roadmap as we go along’, so the classic lower case A Agile system.

The other way is I sell what I called the Trail Map, which is a roadmapping session where it’s – they pay a flat fee, I do all the roadmapping discovery stuff with them, and then they get a document called the Trail Map which outlines where their project should go and – my sample I’m looking at, it’s 25 pages long. I just did one for a client; I think it clocked at 42 pages long, and it’s – the sample one is, I’ll show you guys a link –it’s 25 pages long for a 15-week project. It’s not a very large project. I talk about – but it gets into all that; it gets into the buffers, all that. It’s very, very detailed.

My intention of this is that they can take this into another development company if they wanted to and have them work on it but because I’m being so transparent because I've thought through it, it’s actually easier for me to do it than anyone else.

And that’s a paid service, the Trail Map?

Yes.

Yeah. I do the exact – you just exactly described how I would do a roadmapping session for a dev project.

I've sometimes pitched potential clients for a project work on such a roadmapping session, and they’ve never been so excited about the idea. And maybe I just haven’t pitched it well, so how do you go to them, or first of all, do you do this with all clients, or some clients – I guess some more appropriate for it than others? And second of all, how do you pitch it to them such that they're – they see that it’s in their interest because I believe it is. I believe it’s in everyone’s interest.

I guess it depends on the client. Some people, they have a small scope or they know exactly what they want. And so the first, you email so we get a little bit of information about the project’s scope, and then I’ll get on my internet call with them, talk about it, and if they have a good idea and I can tell they're not basically wanting Microsoft Windows developed in 2 weeks, then I might recommend, ‘hey, here's the two options I’d recommend. We just get started – I can commit to a 1 or 2-week project right now; I think that’s going to be enough time for you; we can readjust as we go’.

Some people, they just – they don’t know what they want and they're willing to just get in and start working on it, and then each week, during the reviews, the side that they want to buy more time or basically, really flexible schedule.

step 1, step 2, step 3, and for them they like the idea of before starting the project, having everything documented. They’ll know approximately – because these are estimates – but they’ll know approximately their cost, the time, how long it’s going to take to do. And so I’ll say, ‘for something of this – the project of this size, if you’re not willing to do on the fly as we go, I have this other service called the Trail Mapping service. Basically, I’ll interview you, I’ll go through your project documentation and I’ll assemble what I think would be the project plan to actually build the software you want. I’ll include estimates and some ranges. You get an idea of where your risk areas are, where your non-risky areas are. Maybe there's some opportunities you haven’t thought of, you can take advantage of. Basically, at the end of it, you’ll get this document that you can review and either decide to work with me or work with someone else. And basically, it’s something you could take to someone and actually start the engagement with’.

In many ways, it sounds like you're saying to them, ‘I’m going to figure out what features you need. It’s obviously part of it but I’m going to figure out where the major wins are and the major risks are. And I know that if I do those for you –’, and right there, identifying the risks is helping to reduce them and that’s what people want – to reduce the risks. [Crosstalk]. And I assume also that as you learn more about what’s going on, and as you can come with suggestions, then the confidence level of your estimates increases.

I see here, just the documents you showed us here – 90% confidence, 70% confidence, and so forth. Whereas if you – we’re just talking for an hour or two, you’re probably at a 20% confidence.

Right. And a big thing is this one client I work for right now where I did this for. They don’t have an IT department, they don’t have a development team, they don’t have technology people in the company, and so for them, a huge risk is – if we build a custom application, or I – I said we – if I build a custom application and it goes down, there's no one there to manage it. And even though I don’t recommend it for most of my clients, I recommended a completely managed system using that [inaudible] and said, ‘it’s going to cost you more. It’s going to cost a bit more pain in the development just because of limitations on the platform but you have a huge infrastructure risk here and this is one way to mitigate it. Another would be to hire an engineer for 50-100,000 a year’. And so I basically compared and contrasted that for them and they're like, ‘yeah, let’s go with that hosted platform. That’s going to be a good option’.

[Chuckles] That's a great contrast. How long does your Trail Map product take? Is this a week-long project or is it usually a day-long thing?

I would say it takes 2-3 days; total time is probably around 8-10 hours but it can be spread out a lot of it is because it’s meetings. So if I have to meet with a couple of people trying to get it scheduled and then going back after that and if there's any follow up. I think I tried to commit to getting it to people within a week after they buy it and we have it scheduled. But it typically takes about 2 or 3 days to put together.

One client I did, we actually went all the way through it. We’re at the final stages and then I had to completely rewrite the entire application so we did start from scratch which it sucked for me because it is a fixed price service, but the end result is they got a lot better – a lot better picture of what they wanted to build.

Reuven asked about how to sell it, too, and there's one thing that I've found that is very helpful, which is to say, ‘look, we’re going to have all these conversations one way or another through the course of the project. It’s going to be better for everyone to front load it and then get all the surprises or as many surprises as we can out of the way and given the findings, –‘ same as Eric – ‘you can take this document – it’s portable – you can take it to somebody else to have them develop it for cheaper. I’m going to do the discovery part, which is the really tedious, painful, notfun part, and if you want to go with me, great; if you want to go with someone cheaper, that's fine too but these conversations are going to happen one way or the other. And you might as well get it out of the way at first because making a change to the Mercedes at the end of the production line is a lot more expensive than making the change at the beginning’. [Crosstalk]

That’s a very clever way to say it.

Yeah. That's actually something – a hidden thing in there which is one, I didn’t actually understand until one of my clients – they didn’t push back but they mentioned it. They're like, ‘you gave us this Trail Map and we’re going to work with you on it, but is there any way that we could take this to someone else and have them do it faster, not cost-wise but timeline-wise?’. We’ll say it’s a 3-month project, they wanted to do 3 developers for – and make it a month-long project.

And so that's the other thing. The Trail Map gives them an idea of, ‘here’s’ – what is it called? Whatever – when you have a flow; what’s the shortest possible route from A to B? It can give them an idea of that and if they could hire a larger team and get it done faster or if the larger team is just going to be sitting there idle and –.

Yeah, lots of independencies in the –.

Exactly. Yeah. And this client also asked or they told me at the end, “one big reason why they wanted the Trail Map was because they were looking at alternative solutions. Instead of doing custom software, what if they paid someone to make a custom Google form for them or use [inaudible] and just did all the stuff back office by hand. And so the Trail Map was actually cheap enough that they can do that as an investigative to see – get them more details of, ‘is it worth doing like this’, or should they just go with the manual route and not even use custom software for it at all’. And so it actually gave them more options, it gave them more information to make – to decide on their business.

That's good. That’s good stuff.

Yeah. I just [inaudible] thing that we’re going to have these conversations one way or another because we know that’s true. Anyone who has experienced the software world, we know that we’re going to have to talk to them about what they want to do and how they want to do it, and walk through the features with them. So we might as well just make it part of up front conversations, get that out of the way, and then understand – have a deeper understanding of what’s going on.

And the part of it is also – I’m sure the biggest thing is the trust. We’ve talked about this a lot on the show in the past that at the end of the day, the reason our clients are working with us and sticking with us is they trust our judgment. And I have to assume – not having done it before – but I have to assume that part of this roadmapping session convinces them, ‘yeah, these guys really are in my corner. They really want me to succeed because they're asking the questions that demonstrate they want me to succeed’, which can only help increase the trust level too.

Yeah. It gives you a chance to test drive the relationship with a very low risk. It’s really a very lowrisk project. Compared to the software project itself, it’ll be a fraction of the cost. And they can get familiar with your communication style, your responsiveness, all that,. And it – yeah, it builds – you're right, it builds up a lot of trust assuming that it’s going well [chuckles].

Have you ever had a roadmap go poorly, or demonstrate it, but it’s not someone you wanted to work with?

I have not. [Crosstalk] on other projects, but not on a roadmap.

I said I had that one where we went down basically the wrong rabbit hole. The relationship was good. I got a little bit of a tension of – or in my part of ‘I just wasted 2 days for work that I can’t bill for’. But it wasn’t that the roadmap was bad, it wasn’t that the client or the relationship was bad, it was more of a business cost type thing for me.

Did you learn anything from the situation that would alert you to in the future or was it just a total black swan type situation?

First thing is to charge more to cover that, but yeah, I think in that situation it came down to budget. We originally thought that there's more budget in the project than expected. And once we actually dug into it a bit more, we found that there's less. And so I think if I drilled into that stronger and earlier at the beginning, that could’ve framed it.

It’s the typical thing. If you have a million dollars to build a software, you're going to build completely different software than if you have 50,000.

Right.

I want to talk about one of the thing that – when we talked about roadmaps – and maybe we should define the difference between the two. The roadmap is the series of things that have to happen in order for the project to be successful and that the estimate is how long we think it’s going to take to get it done or to get particular features done.

Actually, I don’t know. I would call the roadmap is the series of things but it’s also a collection of things. And to me, the roadmapping includes the estimates – the total project estimate or also the calendar time because [inaudible]. I consider estimates to be the actual individual discreet task or features. Also, estimates go together into a roadmap. That's how I look at it.

Mm-hm.

Right.

In my impression [inaudible], again, not having done it, but my impression is that the roadmap document is almost a justification/research for the estimates.

Yeah. Your goal is to get the roadmap. Your client really doesn’t care if it takes you one hour or a month to do user authentication. They care that there's user authentication and that it’s done in a certain amount of time that the project is complete. So the roadmap is like, ‘here's the thing the client wants’. But to build the roadmap, we have to drill into it and put in user authentication, how long it will take, and all that.

Mm-hm.

A good – maybe a [inaudible] test for people who are trying to get their heads around this is that it would be extremely common for me to provide wireframes in a roadmap. The ones that I've done have been very design-y where people have an idea for a web app or an iOS app or some kind of app, and it just have the business idea and they want to – ‘and it’s going to be made from scratch, and how big is – I don’t know how big the scope is. You could go back to your room and get together and you guys could do a bunch of wireframes and you could send them to me to get my head around it but you guys don’t do that stuff. You guys are business people and aren’t familiar with [inaudible] or Keynote or any of the things you might prototype in. So why don’t we start off what could be a gigantic project with $5,000 roadmapping session where I just interview you guys, we go through this thing, we put all these wireframes, we talk about all the features would be, estimate how big it would be once we have that’ and it’s way more detailed.

To me, an estimate means – from back in the day, is something that I would do on an hourly engagement where they need to get some ballpark of what they're getting themselves into financially. And that would be – you have a couple of conversations with them over the phone, you maybe get access to the existing system and the changes they want to make to it. And, we used to have a formula where we would ballpark out, ‘ok, this number screens with these number of widgets. We know it’s roughly going to boil down to this, so we just multiply [chuckles] it out and end up with this number that we always exceed’. [Chuckles]

Yeah. You just articulated why I hate estimates.

I just don’t do them anymore. I don’t do them. I give people a price. ‘This is the price’.

I must admit that part of my attraction of moving more and more solidly into the trainings is that I just avoid these problems entirely which is very easy to say because it means I’m not doing software development for other people anymore, I’m just doing it for my own projects, But it’s such a refreshing change to say to people, ‘here's the price for a day full’ and they say ok and it’s done [chuckles] as opposed to, ‘well, it might take me 3 hours to teach them, take me 5 hours’. This goes away and it’s such an agitation to have to negotiate with people over this.

Does it happen to you guys that you say, ‘well, I think it’ll take a month’, and they say, ‘really? Can you try to do it in 2 weeks?’ Does that ever happen with you?

That’s 2 questions, though. Are they really asking you about the calendar time or are they asking you about the money?

Usually, yes. [Laughter]

I find that people do have concerns about both but they're wildly different. They're concerned about the calendars – unless there's some trade show event or something that they can’t control, deadlines can always – almost always – move. The budget is usually a lot less flexible. The first thing that I would say to someone who asks, ‘oh, is it really going to take that long’, I would immediately be like, ‘are you worried about the actual delivery date or are you worried about the cost?’. And completely separate those two things.

Mm-hm.

I can say it’s a bit different for me. I'm thinking back to a project I had 7 years ago now – that’s a long time. It was one of my first fixed bids and I estimated and I added my buffer into the hourly stuff because that’s how I was doing it back then and came in and – some of the features were wildly over, some of them were under, some of them were like, ‘I can’t believe this really is that simple’. I think I was billing less than my hourly rate on that I ended up – I took a bit too long on it but I still have fun memories of that. I actually enjoy estimating, breaking it down. The client pushed back. It’s a bit annoying but I think what really helped me more recently is I got away from estimating in hours. Actually, let’s be honest, not even full hours like quarter hours – I also take 15 minutes which was like 30 minutes. And now I estimate in days.

The smallest unit unless something is really inconsequential code-wise is a day. And so if I say, ‘yeah, this will take 1-4 days to build this section’. That gives me a lot of room, and that lets me have these larger chunks of features. So it’s not like I'm saying it’s going to take me 15 minutes to make this screen, 15 minutes to put this widget on this screen, 15 minutes to put this other widget on there. I say it’s going to take me a day to build this screen and all the widgets on it. Or even better, it’s going to take me 5 days to build the User Signup feature which includes 4 screens. And I think that has really helped and looking back at the project I’m on right now, even if I break out the estimates I have for the roadmap on this one to the hours and compare that to what I’m actually tracking in my time management system, I’m actually really good at all my estimates. I’m under or right around the midpoint right where I thought it would b, even for the riskier, the lower confidence estimates.

I've always enjoyed it, I think. Estimating is a skill that you have to continuously work on to keep – be good at, and to know where you are if you always estimate higher or you always estimate low – [crosstalk].

I completely agree with that. It should be something that people are getting better at. It’s not really an argument. It’s just – a corollary to that you won’t really get better at it unless you put your skin in the game because you have no real incentive to get better at it if you're not giving fixed bids. You're just like, ‘oh, maybe I’ll hit it, maybe I won’t, and then if I don’t, I’ll just have a fight with the client for a month and maybe I’ll eat some hours and move on to the next project’.

I think you can do it if – even if you're doing hourly. Myself, I don’t like having conflict. Even if it’s healthy conflict like with a client critiquing me why am I 2 hours over. And so, knowing I went 2 hours over on this, I got to go to the client and tell them it took longer, even asking permission to take longer – that is enough pain for me internally that I tell myself I need to get a better at estimating those types of stuff in the future.

I think the thing that really makes estimates a pain point for me is that it usually devolves into some point of contention with the client. Even if you delivered everything they needed before they needed it, blah blah blah blah, you told them one thing or they heard one thing, and for whatever reason, they don’t feel like that’s what they got. And so even if you communicated clearly about what specific things we’re going to take and what was going to be involved, I've just found that in a lot of cases that you still don’t get that support or buy-in because they decided that they heard something else.

That’s actually rare for me. I've really stressed communications and have a lot of feedback and check-in points with my clients. That does come up but when it comes up, it’s usually like, ‘hey, you're going down the wrong –’, not like you're already far down there. I think the only time when it has happened is when either myself or the client really did a very poor job at communicating and if we drill into it, questioning what’s going on, we can usually spot that the client will either admit, ‘yeah, I just didn’t read that email. I’m sorry, let’s just correct it’ or at my part I was rushed and just told the wrong thing or didn’t explain it clearly.

That’s fair and it does match up with my experience, but the thing that stresses me out is the contention and I just – that's the part I remember [chuckles] because that’s the part where I have these heightened emotional experiences where I'm just not happy.

Maybe that's how you're put together. Like I said how I am. I don’t like conflict and so I’d rather be very vocal, be very communicative to avoid that conflict. And maybe that’s just something you need to address. Maybe you shouldn’t do estimates. Maybe you should do fixed bids; they fit your business, your personality, your work style the best. And I think that might be something to explore: what stuff works best for you. Even if we’ll say everyone’s all the rage for value-based fees right now but if that doesn’t fit, the collection of you and your stuff, then it doesn’t really make sense to shove that peg into the hole and make it fit even if it’s not going to work.

Yeah.

Fixed bids. Value-based fees and fixed bids, they do drastically decrease the conflict though. It’s because you're putting your ass on the line and the client never has that.

How many of you guys have hired someone by the hour to do dev work for you? And I don’t mean on a client project – I mean for your own personal thing.

I have.

I have and it was – I didn’t like the experience for sure.

Isn't it? Because all of a sudden – [crosstalk] – you don’t hear from that person for a week, and you're like, ‘oh my god. Has she been working for 40 hours?’ And you're just – I’m in a constant state of freak out when I hire someone by the hour to work remotely because you have no idea until you get that invoice and like, ‘you worked –?’

I have a story where I had somebody just like, ‘oh yeah, I need somebody to redesign my personal site. It’s not a big deal but I know you just left this company and you could probably use the work and I know you're good in your stuff, let’s talk –’, so we get started or whatever. The first week, he worked 80 hours. [Chuckles] So my first invoice was over $3,000 and it wasn’t even like – and so, my bad for not saying – setting a maximum of 10 hours a week or insisting that he have a design review with me every $500 or something. But the design sucked and I hated it. So is that my fault? Maybe. Is it his fault? Maybe. The bottom line is it doesn’t matter whose fault it was; I will never hire that guy again. See what I mean?

If you don’t – it just completely changes the internal – the client’s internal gut feeling about you in every way. Even if he crushed the design and I loved it, it was too much money and I was left out of the process and I was always wondering if the clock was ticking or not. And then when I found that it was ticking and he had burned crazy midnight oil on it, I was mad. He’s probably listening to the show; I didn’t even tell him that. I just paid it and never talked to him again and just took it as a learning experience. Actually, that was something – that happened after I had moved over to fixed bids, but man, did it cement the lesson. I would much rather take on a risk and not be freaking my customers out constantly with this, ‘oh, are you working? Are you working today? How much work did you do?’ And it sounds like Eric addresses that by being incredibly communicative but that’s maybe not conducive to everyone’s style. I like to touch base with customers with an ongoing project – I’ll send them an email, I’ll tell talk to them once a day but I’m not going to have crazy phone calls every other day or something like that. That's just more overhead that I don’t want to deal with.

Yeah. I’m doing weekly billing right now, so that's mitigated a little bit but when I was doing hourly, even one of those crazy hourly was like multiple clients during one week, I would email the client, give them updates at least once a day or something if they weren’t active in a project management system. And some of them might actually would use their Redmine or whatever, and I should be able to [inaudible] login time to their system so they could if they want to actually see, ‘oh, what is he actively working on? What’s he billing us for?’

But I think, going all the way back, I've always had some budget in place whether it was a total budget for the project. So if I want to burn midnight oil and just get a bunch of hours this week, I could do that; or it was like, ‘here's the weekly amount of hours for the month, the amount of hours to–’. I wouldn’t actually go over a camp that we set ahead of time. And if I was going to ever feel like the project is needing more time, I would bring it up to the client that, ‘ok, here's the reasons why. It’s up to you if you want to approve or reject it. It’s your decision’.

And like you said, it might just be me and might just be my over-communication in general. I learned that early on. Most clients were afraid of working for consultants and so communicating a lot actually helped alleviate that fear and also build the relationship up a lot faster.

Yeah. I have to say that, first off, when I've had these problems, usually it’s either I got busy and I

didn’t communicate well, or the client disappeared on me for weeks at a time and then came back and freaked. The other thing is it’s almost always been on hourly projects. And so, the conversations are completely different because then it’s like, ‘what did you spend all your time on?’ instead of, ‘what value did I get for this week?’ or ‘I don’t feel like I got fair value for the overall cost of the project’.

Right. Right.

I think I had a client mention that once, that it wasn’t for the whole project; it was for the features;it was long lines of –.Looking back the amount of time and amount of money they spent on that feature. They didn’t think there was a ton of value there. I think they were slightly disappointed with that, but that was just a portion of the project which they’re happy with. Anyway, it was more of they were just giving meget critical feedback about it. And so, there's nothing we can do at that point but we’re like, ‘ok, that's fine’, and they became a repeat client after that.

I could see that if it’s on a bigger project if they feel like you burned a lot of time on it and there's no value or – we’re talking about earlier – if there’s the value you delivered is hidden value. It’s not very visible to them or visible to their customers but they spent a lot of money on it. That's a really hard sell, and you really have to play up the benefits and the risks and really go above and beyond on communication so they understand the value.

Yeah. And even then, if they don’t understand it, then– I found that sometimes they're still upset just because there's just no way that you can make them understand what the value really was that you brought.

I was like, ‘ok, I can teach these people. I can teach them to prioritize’. But in terms of the communication, we set a Redmine. I said, ‘here are the different tasks that's going in and let’s try to communicate’. And to some degree it was wildly mismatched expectations where they thought the communication was us coming in to their office all the time and seeing how they work so that we could then go off and develop software and I’m feeling that communication was, ‘well, we’re talking on the phone, we had twice weekly meetings on the phone and we’re using Redmine and we’re emailing them with updates and we we’re working on this software with the emergency – basically, it was an emergency situation that we discovered that we had to take care of before we even got to seeing how they work with the software.

So, after one month, basically, it’s clear we have very, very mismatched expectations in terms of what’s possible to do in the amount of time they're willing to pay for – they’ve budgeted for – and how people expect to communicate. They basically called me yesterday and said, ‘well, we’re sort of willing to give it another go’. And my employee and I talked it over a little more yesterday and today and we said, ‘well, we’re not’ [chuckles]. It’s going to be too painful and too long and too dragged out all the time with us trying to convince each other none of the way we want to communicate is the right way.

I think we talked about this on the Red Flags episode where one of the things that came up was that if you have just different communication styles or it’s just like if you can afford not to take the client on, it might be a good choice because it just gets so tedious and it sets you up for a lot of finger pointing later in the project.

Yeah. What I like to do is ask my client or maybe if it’s a lead at that point like, ‘how do you like to communicate?’ - I give examples: ‘I use a project management system and that works good. Here’s what it entails. I can also do something lighter weight and just email you, updates on today or every 3 days – 3 times a week and then have a meeting on Friday and Monday. And it’s nice if you can propose those ideas’. And sometimes they’ll be like, ‘yeah, those doesn’t work for us. We want you in our building every day at 9:00 and stay until 5’ and I’m going to be like, ‘nope. See yah’. [chuckles]

That’s communication, right? You're there every day?

Yeah. Some people want that. That’s the whole draw of the onsite developer, onsite freelancer/consultant/contractor/you’re-an-employee but the IRS is going to slap their hands about it. That’s one of those – like Jonathan said, it’s a red flag and if you can feel that out ahead of time, that’s better but sometimes you can’t.

Right, which is why – and here I’ll stress what I've said before about this project, ‘boy, is it a good thing that we god paid in advance’, because that just reduced a huge amount of discussion, anger, agitation, finger pointing and you name it. Because if they now feel like we didn’t do anything, which is what they feel even if that's not true, and you didn’t communicate, which I don’t think is true either, but we avoid the argument; they’ve paid for it.

Now the question is do both sides want to continue working together next month? And the answer, at least on our side, is no. We don’t need it and we don’t need these headaches, whereas if they had paid in advance, I’d be calling them every day and it would just be boiling my blood.

Right. And that's why if you're going to – if you're getting started with a client, I sometimes recommend doing a trial project where you do a week or maybe 2 weeks – or if you're doing it hourly that amount of work with the client, that’s your contract. You commit to going into it knowing ‘we don’t know is this is going to work or if it’s going to be a good fit or if I can help you but let’s try this; see how it works and then we can negotiate something larger at the end of it.

I've done that a few times and then bailed out because either the skills I have is not the best fit for them, they don’t have the budget, the communication isn't there, they're not active – whatever reason. But having that trial, it gives both parties a good escape where they can say, ‘nope. I don’t want to do this. Let’s just shake hands and part on good terms and walk away’.

Nice.

That is very smart. Have you ever done that in combination with roadmapping or is roadmapping an initial project that you can use then to test the waters?

Both. Roadmapping is a really good initial project, like I said, for the companies or the clients who want a more of a plan-based approach, but it also can serve as a trial project; it can be a – because you're on the phone, you're doing a lot of communication. In my case, it’s pretty much all communication, maybe a little bit of development research of library A or library B and that’s communication [inaudible] with the client that’s usually where your problems are going to come from. Most projects, at least what I've found, they don’t get killed by the technical or the implementation side. They get killed based on client expectations, your expectations, and problems that come up along that.

Yeah. It’s almost never technical. It’s always budget and bad assumptions. So these all reminds me of an adjacent topic that I just want to do a quick shout out to – maybe we could do a show on it at some point – but since we’re talking about estimates and that sort of thing, a cool thing that seems to be the trendiest productized services and I’m actually a big fan of this where you’ve got – trending is almost one of them. It’s like a productized service; [inaudible] delivering a service. But it’s a product; it’s got a price for it, there's a sales page for it, I’m sure, and it’s got details – this is the hamburger you're going to buy. It’s $2. And even though it’s a high-touch delivery, it’s still a manual item essentially. And I’m seeing – I’m [inaudible] bunch of people are a center ground creating productized services.

And it’s pretty cool in terms of just being able to say, ‘here's what I do, here's what it can do for people, and here's how much it cost’. And if you're the right kind of person in the right stage of your business, you can expect these kinds of results which will make the price extremely affordable’. And it creates a value-based fee type of model but it turns it around in a way – flips it on its head and allows your potential clients to self-select based on how much value they think they would get out of this thing.

So you never have to do a proposal. I actually have some people fill out an application just to make sure that I agree that they're going to get some value out of it because I also offer money-back refunds, so I want to make sure that I’m engaging with people who are going to capitalize on it and make the money back. But it flips the whole thing around, but it still operates on this same fundamental principles of a value-based approach. And it completely sidesteps the hourly thing and estimates and proposals and all of that which is really interesting. [Crosstalk]

That's actually a lot of how I've done the roadmapping stuff. Roadmapping is weird. It’s – because it’s actually been packaged up like that by other companies so it’s more known, but I've seen that; I've actually for the past 4, actually 5 months, I've been working on productizing some of the services I offer, they’ve been hidden and not really public. I’m trying to test them out before I launch with them. But yeah, it’s the idea of you fix the price, you fix the scope. The customer would selfselect to figure out what level of value they get, but the value is pretty fixed or is fixed within a range so they know if they're going to sign up for this, they're going to get x to y amount of value and it’s supposed to really help out on the salesmanship of it and actually when you're doing it you can also really refine your process so you're not going completely custom. You can actually say, ‘yes, I know. We’re going to do steps 1, 2, 3, 4, 5 and then you will get your – whatever it is you bought, and it would give you the exact value you need’.

Yeah. It’s definitely true that the proposals that I've had to do for training are just laughably easy, short and small and non-negotiable compared to the project ones because basically I’m saying to the company, ‘here's my course’– it may[inaudible] Jonathan – ‘here’s my course, here’s what I'm proposing in terms of price’. And usually they’ve also come to me. They say, ‘we really want to hire you to do x y z course’, and I say, ‘ok, great’. And sometimes they have to chase me down to do a proposal because it’s like they really want it so much [chuckles]. But there's no – sometimes, there are companies who will say, ‘really? That’s the price? I don’t know. Let’s negotiate’. But fortunately, there are enough fish in the sea or whatever the analogy is you want to use there that I don’t have to worry about it too much.

Mm-hm.

Well, it also starts the discussion, if they're coming to you for training and saying, ‘we love everything about your training. We love the value you're going to provide the topics but we don’t agree on the price’, you could do something custom for them where it’s higher price, lower price, whatever. Or maybe like, ‘hey, we agree on this, but we want you to cover this extra module’. And so it ends up – it’s a lead generator for your actual custom stuff but you have this framework you can go on and this idea and concept that they can actually see and figure out and sell themselves on before they actually get started and contact you.

Precisely. One of the things I've been working on slowly but surely is redoing my website so that it’ll have – it’ll be very clear, ‘these are the courses I offer, here are the syllabi. Oh, you want custom modules? Great. Talk to me, call me, let’s discuss it and I’ll charge you for that’, But people will know because they’ll know that they're going outside the boundaries of what’s normally expected and part of the package.

Right. And it’ll be anchored against the price of the non-custom one.

Yup.

But the nice part about the productized consulting thing is that you can make it – I think Kurt Elster has been on the show, I’m not positive. He has a really, really successful productized service called Website Rescues for Shopify store owners. And he’s getting enough leads in business that he can adopt an attitude of ‘buy, don’t buy, I don’t care’. I don’t think he does any custom work anymore. He’s much more interested in automating his workflow and creating systems to deal with the flood of leads and how to set his pricing and how to do delivery. And he’s really – it’s really changed the way he does business.

And it’s super interesting to me for a development background. If I was still doing a lot of development, I would be going full force in this direction of just finding expensive problems that can be solved with software development for a group of people who stand to benefit greatly from it. Reuven, you mentioned the things that you're going to put on your website but you didn’t say what they should expect to get out of it which should be the very first thing on the page. And Kurt’s amazing at that where it’s like the very first thing is, ‘here's what you can expect to get after working –after paying for a website rescue’. And for people that have – whatever – noobs that have little stores that sell the used books out of their basement, they're not going to be able to afford it because it doesn’t make sense to them but he never has to talk to those people because the price is – I don’t even know what the price is, but I’m sure that my grandmother who’s trying to get rid of her old Danielle Steele novels is not going to pay him. But somebody who’s got an actual million – 2-million dollar business selling jeans or something, they’ll be all over it because they see immediately that the benefits wildly exceed the cost.

That's right.

Yeah. He’s done really good at self – not – yes, selecting web market he works for. He’s not working on the very low and he’s not working on the very high where [inaudible] local company but Nike’s not coming to him saying, ‘we want to rebuild our entire e-commerce system’. So he’s like, ‘here's my area, here's the people in that area, I can help, I help them with this problem. If someone comes to me and they don’t fit that, this is what I do. I refer a map, I [inaudible] client completely –whatever’, and I think that’s really important.

I did that a while ago when I was just focusing on Redmine and it was – I didn’t do it to [inaudible] on it. I did it like, ‘if you want a Redmine work, and you could pay certain rates, I would probably work with you’. Kurt’s really – he’s really optimized – I've talked to him a lot. He’s done a lot of good stuff with it. That’s a good business model. That’s a good way to run your business if you want to go that route versus doing the custom stuff all the time.

Right. Right. I must admit when I heard that Kurt was doing Shopify optimization, I said, ‘really? Really? Is it that much of a business and market in there?’ And, boy is there. It’s very clever.

That’s a funny thing. Is it the scale? The human mind’s not great at giant scale. Our brains just don’t rock it. I was talking to someone the other day about focusing – trying to switch – he’s a solo consultant doing software development but he’s a complete generalist. His list of his last 10 clients was almost laughably heterogonous. It was just like a food delivery service, a pet shelter – it was insane. But, I think that’s the experience for most people because they're just like, ‘oh, I know these powerful things with software and I can do [inaudible] beneficial for everyone’, which is true. But it’s really hard to sell to everyone. So if you're having a problem attracting clients or getting leads or that sort of thing, a very useful thing to do is focus on a particular market even though I understand that you could build something for a dentist as well as you could build it for a school teacher. If you just focus on the dentist, then you can much more easily speak in their language and get in front of them.

And I was having this conversation with him, and he was like, ‘yeah’ – but he had the classic reaction which is, ‘yeah, but then I’m shutting out everybody who’s not a dentist’. And I was like, ‘how many dentist do you think there are in the United States?’ and he said, ‘I don’t know; a couple of million?’ And I was like, ‘how many clients could you service in a year?’ and he was like, ‘I don’t know – 10?’ [Chuckles] So, end of story.

Right. How many clients do you really need in a year is what it comes down to.

Right. And are they new clients or repeating clients? There's years where I didn’t pick up a single new client because I had my repeat clients – my past clients that just kept renewing or kept wanting more work. You might work for a dentist in your local area and you work for 5 out of the 50 and that's all you do for the rest of your life. You never lose them.

But I think one really interesting concept that I like about productized consulting is – like I was saying earlier, you can refine your process and you can really pick and choose what you do. So to offer that money, Kurt can actually look at a Shopify store now and within 5 minutes give the client an estimate of like, ‘it’s going to take this much work, it’s going to cost this much to do this thing’. He has the domain experience. He has the skills, experience. All of the – or like in my case, the confidence amounts have gone so high because he’s done it over and over versus your [inaudible] Jonathan and that other developer – ‘I know myself; I’m in so many different areas right now that I have – I’m a jack-of-all-trades type of idea. It’s going to take a bit hard. It’s going to be a bit hard to get a better confidence because I’m in so many different things’. And so that’s a nice little improvement especially if – you're talking Chuck like it’s hard for you to do estimates or to nail down that stuff. Maybe focusing on something where you’d know at the drop of a hat it’s going to take x days to build this feature, that might be an improvement you can do.

Yeah. Yeah. I like the idea of doing something like that where it’s focused and well thought-out because it’s something that I've done a lot of in that way. When somebody comes to me and say, ‘hey, what are we doing here?’ Then I can give them an estimate or I can give them a roadmap, a timeline, whatever you want to call it, however you want to look at it. But I can say, ‘this is what it’s going to take to put it together. This is how much it’s going to cost. This is how long I think it’s going to be’. And basically, I can just sell them the product for it and just make it go that way. Interesting.

Alright. Well, should we do some picks?

Yes.

Good idea.

Alright. Eric.

I got two.

You want to start this off?

Yeah. I’ll put a link on it or I won’t. Mandy will do it because I don’t know how to put it in there but I’ll give you a link to my sample Trail Map. I have a sales page for it but for some reason I haven’t actually updated it and put the sample on there. But I’m willing to share with everyone; it’s just a very basic – I said it’s 25 pages, but you can [inaudible] if you know software development and see how I organize all this and how I do estimates. So I’ll make that my first pick.

Things That Gain from Disorder. I’m not even going to pronounce the author’s name. He’s written The Black Swan, Fooled by Randomness, all that stuff. It’s very interesting and it’s – I think he was in derivative [inaudible] financial but he’s looking at how different things can be affected by events like stock market crashes, that sort of idea.

The first half was a lot of background stuff, and the second half, I think, every few pages I was taking notes of how it’s going to affect my business or even the software development work industry in general of how the industry actually responds to certain things. And it was pretty interesting; pretty enlightening of how my [inaudible] would’ve happened. I could actually take some of these principles and apply it to the past and see like, ‘yeah, that's exactly what happened’. So I highly recommend it. It is a difficult book to get through. He gets a lot of examples which will help cement the concepts, but it is worth it. It’s a good read-a-little-bit-each-day type of book.

Alright. Reuven, what are your picks?

Ok. I also have a book for a pick but it’s a slightly lighter one. It’s a children’s book that I just read with my 9-year old. It is so fantastic; it’s called The Terrible Two. The basic storyline is that this kid comes to a new school and he was the best prankster at his old school. And he arrives and discovers there's someone who’s better at it than he is. And then, of course, the ultimate ending is that they end up pranking stuff together. It is incredibly funny. It’s very clever and I say that there's already a sequel planned that will be coming out in January. And the moment that I tell my 9-year old this, he’s going to be extremely disappointed that he has to wait so long until it happens. So I definitely recommend The Terrible Two as a fun children’s book and also one for grownups to sneak when the children are asleep.

Alright. Jonathan, what are your picks?

Ok. The first one is called Inbox Pause which interestingly is a Chrome extension that you can install. And it actually affects all of your devices which is good for me because I have a million devices; I’ve switched between phones, computers, and iPads, and other tablets all day long so this works great for me. And it’s a product that shouldn’t need to exist but does exist [chuckles] because most people are like me; they have really bad self-control about checking email. What it does is it just puts a pause button – the top left button of your Gmail inbox; it’s Gmail only – and you press the pause and it gives you a configuration screen that allows you to set a couple of options, the most important option being when mail hits your inbox.

And what it does is – I've got it set for every 2 hours from 5am to 5pm – it takes all of the pent-up email and it lets it into my inbox so I get one gigantic notification on all my phones, all my Watches and everything. And I try to – it’s funny because before I started using it, I thought it was pretty good about not checking my emails constantly because I’ll get notifications – I look at my Watch and I’m like, ‘oh, that’s not important, I’ll skip it’; another one comes and I look at my Watch, ‘oh, I won’t worry about that until later’. But now that they all come in at once, I realize that even just looking at my Watch was a major – created cognitive distance. It would pull me out of the moment of whatever I was doing and distract me even if I decided to ignore the email. And so now that they come in just in a big lump batch every 2 hours, so far, has been awesome. And after 5 o’clock, I get no email until 5am the next day.

There’ve been a couple of issues with it where I need to do a password reset and I need to get the email immediately but what it does is it takes all of the email and it sets up a filter rule – if you're familiar with Gmail – and it puts all the email into a skip – anything from asterisk, skip inbox, and put in this custom folder that it creates and then on this timed, these periodic intervals, it just takes everything out of that folder and puts it back in the inbox. So you can just go check that other folder if you're looking for an instant email like a password reset or something. So that has been just really wonderful. I would suggest that people check that out.

Another one that is probably been mentioned on the show in the past – I don’t know – but CloudApp is a Macintosh app that you install. It puts a little menu [inaudible] at the top menu bar along with your Wifi, Dropbox, and everything else. It just makes sharing files so incredibly frictionless that I don’t know how [chuckles] I can live without it. If you spend a lot of time in Slack or IM or whatever IM client you're in – Twitter, whatever – if you're doing a lot of text and you tend to share links to files and what-not, you can just take a screenshot [inaudible] the desktop or whatever Watch folder you have and it just automatically uploads it to this cloud service. And then it copies the URL to your clipboard, so in 2 – not even 2 seconds, under 2 seconds, you can take a screenshot and just wait for the Ding and then hit paste into whatever check line you're in and share that link to that file with people.

People probably heard about that before but the new thing is that they added – it’s a beta feature now – but they added a button on the webpage for, say, PDF or a PNG file. You can actually annotate it right in the browser. So a very common workflow for me is that I’ll be chatting with my lead developer in Slack. I’ll say, ‘hey. I noticed a bug on the login; error message or something; there's a typo’. I’ll take a screenshot, it automatically uploads, I hit Apple O, it opens it up and I can draw an arrow around the thing that has the typo. And then just hit Save and paste it into the chat box; it’s almost instantaneous sharing of files – annotated files. It’s really, really cool.

This sounds pretty great.

Yeah. That's CloudApp.com. I think that’s where it is [crosstalk]

It’s GetCloudApp.com.

There you go. That's right.

Alright. I’ve got a couple of things I’m going to share. The first one is a book. It’s called Traction. Now, if you go look on Amazon, there are two books called Traction; one has a yellow cover and it is about basically, finding and growing your customer base for your SaaS app – that’s not the book I’m recommending – it’s the other one by Gino Wickman. And it’s really awesome if you're running a small business, and it basically talks about how to organize your company. It’s built around this system he calls EOS which is the entrepreneurial operating system but it’s just how you run your company. And I got a lot of great ideas out of it and I’m implementing some of the stuff from it. So I just wanted to recommend that.

So if you have people working under you or you're trying to solidify accountability and other things in your business, there are a lot of great, great ideas in there. The yellow one is great too. I read that one first and it’s awesome as well. But I think I've picked it on the show before.

Another pick I have is 99Designs. I used that to get the design done for Ruby Remote Conf. I

actually got the design done for JavaScript Remote Conf and then I just changed the names to protect the innocent [chuckles] on it. So, why not, right? But anyway, I really like the work that I get down there.

The other one that I’m going to pick is Fiverr. Basically, one of those fancy schmancy email signatures hold together for me. I just think they look professional and whatever. So, I’m going to pick Fiverr, as well.

And that's pretty much all I got. So, I don’t think we have anything else. So, we’ll wrap up and we’ll catch you all next week.