Productize Your Service (or “Charge For The Work You’ve Already Done, Again.”)

One of the things that I often hear people talking about is whether or not they want to work on products or if they want to work on services.

Or, more specifically, they’ll ask:

Do I want to be a product company, or do I want to be a service company?

The truth is, I’ve done this myself.

I’ve had the pleasure of working with a team of other guys at 8BIT where we built Standard – a product by a product company – as well as for myself under the freshly re-branded Pressware – which is a service company.

And to be honest, I teeter back and forth between both: I enjoy working on products, and I enjoy working on services.

Each comes with their own advantages and disadvantages, and there’s a lot to be said about both, but the purpose of this post isn’t really about that.

Productize Your Services

One of the things that I like the most about building solutions for others is twofold:

• It presents problems that I may not otherwise encounter on my own
• It solves a problem for someone else

Nothing too outlandish, right?

But here’s the thing: Not every single project is unique. There are times where the same problem needs to be solved across different projects (or even in the same project, if I’m being honest).

Unique Ariel is Unique (and I do not understand!)

And therein lies the opportunity to productize a service.

Honestly, we see this all the time, though I’m not convinced that everyone who’s in the service-oriented business of development sees this as an opportunity.

But here’s one scenario as to how it could play out.

1. Given a Set of Requirements…

So let’s say that you’re working on a project, and a given feature requires that you allow uploads from the end user.

The uploads should only be able to be performed by a certain user role – let’s say administrators – and it should only be of a certain file type – let’s say a PDF.

No one else should be able to upload files, and the feature should fail gracefully and display an error message if anything other than a PDF is provided.

2. Recognize a Common Problem

Later in the project, say that the requirements call for only administrators to be able to upload a certain type of file.

In this case, you already recognize that a module from the first set of features can be reused. Specifically, the code that enforces administration-only uploads.

Next, you can easily generalize the code for uploading PDFs by specifying the file type upon, say, instantiation of the class; however, this particular nuance is more code-oriented than I want to get right now.

3. Generalize The Code

At this point, you’ve got two potential areas in which you can generalize your code to solve multiple problems.

In other words, you spend time developing the solution once, tweaking and/or generalizing it a bit for another set of features, and then reusing the code.

At this point, you’ve done the work necessary to satisfy the requirements of two features by spending the time developing the solution while working on the first feature.

4. Productize!

Here, you’ve essentially got yourself a utility – an internal product – that you can reuse to solve common problems.

But here’s where the tension comes in: the first time around, it took you more time to develop the solution than it did for the second, third, and fourth features despite the fact that they were very similar in nature.

Does that mean you shouldn’t charge for the time to solve all but the first feature request?

No.

In any other industry, people productize their services all the time. They take a given set of raw materials – their code – create a solution that’s used by others – the feature – and then sell it over and over despite the fact that the process by which the service has been refined.

An Real World Example

Look at, say, having your tires rotated:

• You walk into a body shop or garage that does tire rotations. You know they’ve done them before. You trust them specifically for that.
• You accept that you’ll be paying for the time that they spend rotating the tires.
• You request that your tires be rotated.
• The mechanics take your car and, through the process they follow all day, they rotate your tires.
• They return the car to you.
• You pay and leave.

“Is this the real life, is this just fantasy?”

There’s not much difference between this and things that we do with software:

• A person requests out services and hopefully have found us via word of mouth or know that we’re a reliable resource.
• They accept that they’ll be paying for the time we spend working on a solution.
• They request that their solution be built.
• The developers that the problem and, through processes they’ve developed, install a solution.
• They return the product.
• After it’s proven to work, they pay and leave.

In this scenario, the service is the same day-in and day-out. There’s no surprises – you know what you’re getting, you know it’s been done before, you know it has to be done, and so you pay.

This Isn’t About Pricing

Now, in terms of pricing, that’s a whole other issue that would turn this post into something much longer than it already is, and it’s not really the point that I’m trying to make.

Instead, what I’m saying is not only should you look for opportunities to reuse code, tools, libraries, and so on that you’ve developed as part of the same project (or another project), but that it’s also okay to pay for the time spent developing the solution the first time around, each time that you’re faced with solving the problem.