Edit: BTW, great article. Thank you.

2) Clients are buying your availability, they aren't buying bump-what-you're-doing-now. (That's a separate service, and ridiculously expensive.) If they find makework for you on the 29th, you tell them "Gotcha, I'll tell you when it is done and we'll count it against this month's allocation." If they balk at that, you can tell them that happily your email address works all 30 days of the month and that they can get in their requests quicker for faster turn-around.

Of course, the ultimate protection against clients being impossible to work with is not working with them, but -- again -- I'd wait until you actually had a problem before rejecting them for that.

The benefit for the client is that they don't need to review and sign a brand new Statement of Work whenever they want to change a button's color or tweak a feature.

Should your client need work that will seriously disrupt your schedule / happiness... I wrote my thoughts on that a few months back: http://planscope.io/blog/should-you-charge-more-for-a-rush-j...

1) In my experience - it doesn't happen.

2) The way I set it up to alleviate that fear, before I saw that it didn't happen, was to separate the booking time from the delivery time. So $client gets N days each month when they can ask for a booking, which will then get scheduled in over the next 30 days from the point they book it (so if the client requests N days on April 15th, they get booked in any time from Apr 15-Jun 14.)

This will also keep you from being surprised when someone wants their 10h/(month|week|whatever), and may actually prompt you to recommend how to use that time. They will pay you for leads on additional work because they see that it's a winning situation for them.

This could be turning up and running email campaigns to improve retention, or it could be the wider world of finding a niche in a nice industry that is about to get disrupted (all of them), working out what the world will be like after it is hit, and becoming an expert in that business model / software

It turns out writing software at the dynamic language web request processing end is nothing particularly strenuous. Which means some great tools get produced quickly which means the people who can sell a solution dont necessarily have to be the ones who can write it.

What I think I mean is that increasing customer conversion for SaaS companies is a lot less coding than it is getting the gig and introducing rigour into an ignored process

If you want to stay ahead of the game - well I am not sure, but its likely to be find a vertical niche, where specialisation wins or find new technical integrations where early wins (such as uses for UAVs) - but combinations appeal to me - I bet there is scope for GPS in waste collection lorries for example, and across europe thats a multi billion dollar industry

As a stopgap, offer to invoice after the month, not before: "That way if I'm not there when you need me, you don't have to pay."

THanks for the reminder

"Many things are easy for software companies in a way that they just aren't for non-software companies... doctor's offices don't think of APIs for the same reason that developers think that free soda is a wonderful thing to treat your employees to."

I read that as encouraging developers to look at doctor offices as a valuable market without warning them about the importance of HIPAA/HITECH compliance. And I believe that can get folks into trouble if they aren't careful.

Perhaps I should have simply phrased it that way instead. Thanks for the feedback. I deleted my prior message and I'll email Patrick with my concern.

"exact details _for_ what you get paid for"

i.e "for what", so I'm not asking exact rates, but more concrete details of the job he has done. And this could be a hypothetical case. So, basically, did he implement some code, or told to implement with very specific details (e.g. at API/types level) to the senior engineers from the client company? Did he work on copywriting or similar? Did he help to determine exact price of the targeting product; etc...

Anecdote: reading [0] in Patrick's last Friday email was a light bulb moment for me. The timing was perfect as I was about to throw pre-launch page for http://www.ASPSecurityKit.net . Though the product’s target market is primarily software developers, still the copy should address what kind of systems they can build with the product I’m proposing rather than listing the raw technical features “activity-based, resource-aware authorization … Blah blah” and expect them to think what they can build with it.

[0]: a consultant hired to build an in-house CRM wouldn't pitch "Our CRM is going to be easy to use", they'd pitch "Your sales team will close more deals in less time when using our tool."

Edit: As a consequence, made it to HN home page, and collected a lot of interested folks' emails (in 3 digits).

Yesterday I was actually looking forward to your email ahead of time ;)

or is this just another way of self promotion?

I hope your day improves, because it looks like it isn't going so well by the tone of your comment!

Personally, this is the stuff I want to see on HN. Educational content that helps me towards my own goals as a developer and content producer.

I've recently discovered a skill I never knew I had - and one I'm way better at than being a developer. I'm really good at working with non-technical people who want to build things. I can explain technical things to them in a way they understand (because I was in their shoes for many years). And most importantly - I can quickly grok what business problem they are trying to solve and think of way better ways to solve them than whatever strategy they came up with ("I want a site that has like dropdowns and a calendar and logins and maps and a place where..." when a two page lander+them doing everything manually, would be a better and cheaper way to test their idea).

Ok so my question is, how do I market that service (not where to find clients but how to pitch them)? What do I call myself? Should I just charge them hourly/per project (and offer the 2-day a month retainer) or is there a better model I could sell them on that could be more lucrative for me and a better solution for them?

A contractor is an order taker. A consultant is a trusted advisor.

You'll pitch to a different level (middle managers and above) but you'll also double your billing rate. It works very well with companies that don't have a CIO/CTO/VP of IT and are struggling but don't really know why.

The epipheo guys are pretty good at putting business pain into a short message. You may not want to have cartoons, but watching their videos can give you quick insights on marketing your solutions.

As for what to call yourself, incorporate and go with "principal consultant", "founder", "CEO", whatever. If you specialize, use that in the company name or as a subtitle on your letterhead/email sigs/cards/etc.

There are complete consulting firms built on doing Product Management alone.

The kind of non-technical people I work best with don't even usually know what product management means and I'm also doing the development, but that's a good lead. I'll check into it.