Once you've figured out what kind of product you want to create, the biggest hurdle to get it in front of customers is finding the right price.

How much you should charge for something can be a paralyzing question, keeping you from either shipping or making you offer your product for free longer than is healthy. Remember, you should charge even for a beta product.

It took us months to settle on a price for Travis CI, and it was a grueling process at times. We didn't know what to base our price on, and we didn't know what to charge.

Here's what helped us figure out what to price.

Narrow down your target audience

Ideally, this has happened before you even start thinking about the price. Finding an audience for your products is an important step, and it requires research. We like getting lost in what Amy Hoy calls the idea quicksand, without making sure something is ready to pay for what we're trying to build.

In the widest sense, Travis CI's target audience are developers. We narrowed it down further by focusing on people using GitHub as well.

While our open source platform is free for everyone, our product had a slightly different focus. We narrowed it down further to businesses.

That allowed setting a higher price than if we were to focus on serving all kinds of developers.

Don't get me wrong, we'd love to do that eventually, but narrowing down our initial product audience allowed us to validate the product quickly and ramp up revenue to a point where we can focus on possibly starting to sell the product to individuals as well.

Ignore your instincts, focus on value instead

Your gut will tell you silly things like asking yourself "How much would I pay for this?" or "No one will pay X amount for this." or "Lower price equals more customers, right?"

Those things are really silly, and your gut is a liar.

Products, especially the ones targeting businesses, focus on either reducing a pain or burden, or at giving a customer better means to make more money with their business.

That in turn means your product has a value to these businesses. While you may never be able to fully evaluate how much exactly your product saves your customers, you can get an idea when you're familiar with their business. This requires research as well, so it helps choosing an audience you're already familiar with. It's the one reason why I like focussing on building tools for developers.

Developer tools speed up parts of a team's workflow by removing either an operational overhead or by automating something that the team would otherwise spend tedious amounts of time on.

That time can be put into numbers, even just with rough calculations.

Values goes further than just thinking about these numbers, but they give you an idea on where to put your price.

If your product frees up 10 hours every month that a team can spend on their core business, you have an idea of what you can charge given a normal price for a developer hour.

If your product allows someone to learn a new technology quicker than having to scrape together a bunch of resources, tutorials and articles from the interweb, you probably saved that person some time with your product.

That's where you can start getting to a better price than what your gut is telling you. Focussing on value gives you another benefit, you can drive your marketing based on what your product does for your customers rather than just its features.

Charge more than you're comfortable with

Amy Hoy put it very succinctly. Once you've narrowed in on a price, double it.

Back when I launched the Riak Handbook I originally had much grander ideas in my head. I set out to write the NoSQL Handbook, a hands-on guide covering five different NoSQL databases.

My initial price ideas were to charge $12 for the final product and $9 during the beta.

If you ask me now, I have no idea what I was thinking. My mind was anchored by what publishers charge for their books, and by what some fellow self-publishers charge for theirs.

I eventually decided to cut a smaller book from the bigger version to have something to ship. I decided to publish the Riak Handbook, clocking in at 120 pages of content focussed on practical Riak usage. The NoSQL Handbook would follow later.

Rather than charge $12 for the Riak Handbook, I doubled the price to $24. Later, I figured that $29 is a much more appealing number. The book sold 1500 copies so far, making much more money overall than if I'd have sold it for $12.

Hold on, you say. Surely, cutting the price in half would get more people to buy it, yes?

To make the same revenue the book made with a price of $29, it would've needed to sell more than 3600 copies, close to 150% more.

Charging less doesn't mean you'll get more customers, it just means that your profit margins per customer are much smaller.

For Travis CI, we applied similar thinking, and we spent time calculating margins. We even got advice from someone who wanted to invest in us to not charge less than $99 per month.

We settled on that number, but eventually raised it even further.

The beauty about charging more now is that you can always charge less later (though you should really charge more). You can always introduce versions of products for people who want to pay less by reducing the scope of features.

Charging more than we're comfortable with is frightening, we fear someone saying no to the price.

But what really matters is not the people saying no, it's the people who say yes, the people who are willing to pay what you ask for.

Fewer customers at a higher price means getting to sustainable revenue levels faster.

Read, read, read

Pricing is a broad topic, and I've only scratched the surface. Things get much more interesting when you get into the realms of anchoring, using free as a means to sell, upsells, cross-sells, and all that jazz.

A few books helped me greatly to figure out pricing, or at least to get better at it, and I wholeheartedly recommend you read them too:

• Don't Just Roll the Dice
• Pricing with Confidence
• Predictably Irrational

If you're interested in learning how to find audiences, building, marketing and pricing products, I highly recommend Amy Hoy's 30x500 class.

I came across an article called "How DevOps is Killing the Developer." It mourns the rise of DevOps and an ever increasing set of skills a developer has to have to work in the resource-constrained environment of a startup. The assumption is that a developer has to fill all these roles even though his position is at the top of the company's hierarchy and no one else can do what they can.

I can relate to mourning how things used to be. Writing code is fun, and it's understandable that a developer would want to work on it all day long.

I'm intrigued by this notion of DevOps and the assumption that no one else can do what developers can do, therefore they should be doing what they've specialized to do.

However, times for developers are a-changing and DevOps plays an important role in that.

This is my view of the situation, about what DevOps is about and the change developers are facing.

DevOps is about shared responsibility

The author claims that DevOps stems from startups. Resource constraints and the need to quickly respond to an everchanging market require developers to fill roles that no one else can fill. I've done my fair share of that, and it's certainly a valid assumption.

However, DevOps has different goals than developers knowing all the infrastructure automation tools out there.

DevOps is about tearing down silos in more traditional companies, where there's a much stricter separation between development and operations.

It's a cultural shift that fosters people working together, towards a common goal, which ultimately leads to serving the customer.

The totem pole described in the article is the exact thing that DevOps is trying to improve. In a more traditional sense, it's described as the ivory tower of parts in an organization, whether that be operations, development or your quality assurance team. The tendency is to throw things over the wall, let them handle it, and not bother with whatever happens after the release anymore.

The ultimate beneficiary of whatever anyone in the company does should be the customer. The argument that developers are too expensive for any other tasks than writing code suggests they're too good to talk to customers, to fix their own code, to see where it breaks in production under their own responsibility, to see how it affects customers.

Customer support falls into the same reign. Traditionally, company's have a front line support team to weed out the unimportant support requests, best to be done by replying with canned responses. Everyone loves those, right?

The outcome is that developers shouldn't just sympathize with their operations team, the people who run their code in production, they should sympathize with their customers.

DevOps pushes the focus of everyone towards working together rather than a single person trying to wear as many hats as possible at the same time, which will inarguably lead to burnout.

The resource constraints of a startup are a natural cause, at least initially, for people having to do whatever it takes to make their product succeed. It doesn't have to be that way, of course, but improving the constraints is up to the company's entire team, at least in a world where people work together.

Ultimately, DevOps is about empathy, with everyone on your team and with your customers.

You build it, you run it

In this world of silos, development threw releases at the ops or release team to run in production.

The ops team makes sure everything works, everything's monitored, everything's continuing to run smoothly.

When something breaks at night, the ops engineer can hope that enough documentation is in place for them to figure out the dial and knobs in the application to isolate and fix the problem. If it isn't, tough luck.

Putting developers in charge of not just building an app, but also running it in production, benefits everyone in the company, and it benefits the developer too.

It fosters thinking about the environment your code runs in and how you can make sure that when something breaks, the right dials and knobs, metrics and logs, are in place so that you yourself can investigate an issue late at night.

As Werner Vogels put it on how Amazon works: "You build it, you run it."

The responsibility to maintaining your own code in production should encourage any developer to make sure that it breaks as little as possible, and that when it breaks you know what to do and where to look.

That's a good thing.

The developer is dead, long live the developer

It's okay to mourn what we used to do as developers. Heck, I enjoyed writing code too, when I started out as a developer.

But the specialist developer is becoming a liability for any business that's competing in ever-changing markets (which are all of them).

This doesn't mean that a developer should be doing everything at the same time. But they should be ready to when the need arises. It benefits the entire team they're working in.

A developer probably doesn't need to know all the available automation stacks out there. Knowing one should be plenty. What really matters is the willingness to change, to learn a new stack when necessary.

Having more wide-spread knowledge about the environment their code runs in gives a much better picture on how the code can be improved to run better, in production, to serve happy customers.

Here are a few more noteworthy responses to the blog post above:

• Confessions of a Full Stack DevOp by Michael DeHaan
• DevOps and enterprise inertia by Major Hayden

We love grand ideas. As engineers in particular, we like the idea of building something big that solves an idea we've had. We love sweating the details, we love refining architecture, we love building the right tools for the job.

When you start a business, this approach can foil your grand idea before you even hit a market. This ignores that ideas alone are worth nothing without a market for them.

What if, instead of working on your grand idea right away, you start working on something small?

When you've found a market you don't instantly need to build a big product to serve it, you can start much smaller than that. Starting small has the benefit that you can gauge out the market and its interests and that you keep risk lower than with building something big right away. Products are shrouded in uncertainty, keeping the risk low means keeping your losses low, which is rather beneficial when you're bootstrapping.

Building something small initially and slowly increasing the scope of what you build has another benefit. Your initial products start feeding into the work for the subsequent products. The money made from your first products helps you to build more products.

Smaller Products can beget more, slightly bigger products. I love this idea, also called "stacking bricks."

The Riak Handbook turned out to be such a product for me. Working on it took the better of three months, a big part of that spent full time on writing, editing, creating the publishing workflow (I wouldn't recommend building the publishing chain yourself), and the marketing site.

While the book's most sales happened in the first days of going public, it continued to sell for now more than two years, both on the site and on the Kindle store.

It helped a lot in getting Travis CI off the ground as a product. It wasn't a lot of money that came in, but for the following twelve months after publishing the book, it brough in up to $1000 per month extra. Quite handy as passive income when you're working on bootstrapping another product.

How can you build something small before building something bigger? Here are a few ideas.

Build an audience with writing

The Riak Handbook started out by way of this very site, if you will. Early on in the craze of NoSQL databases, I started writing about the fun and silliness I had playing with some of them.

That in turn led to the idea of the NoSQL Handbook, which, after more thought, distilled into the Riak Handbook.

I unknowingly built up interest for the technology, just by sharing what I discovered playing with them. The joys of new technologies.

Sell what you learn (and what you know)

A book or even a series of screencasts is a great means to start stacking the bricks. It's a nice next step from building up an audience, and it doesn't even require you to be an expert at something right away.

Rather than dump your entire knowledge into a book, write about what you learn, or learn as you write.

Here's a little secret: the Riak Handbook was my personal Riak learning experience.

Sure, I've had exposure with it before, working for Basho and with their customers, but my deepest exposure with all facets of Riak was writing the book.

It turned out to be a great learning experience for distributed systems and for Riak itself, even picked up some Erlang along the way.

Sell something that doesn't yet exist

Here's a crazy idea, before you actually build something, sell it. Put up a landing page for your product, start marketing it, see if someone bites.

If they do, you have all the more incentive to actually build it.

I'm a big fan of grand ideas myself. But the Riak Handbook, as small as it is, was a convincing exercise that it pays to start small. It pays off slowly, and revenue will start trickling in, but as you add more products, you add more revenue.

Heck, if you enjoy writing and selling books, keep doing it. Build more, sell more of them.

For some more inspiration on starting small and building your way up, I'd highly recommend these books:

• The $100 Startup
• Start Small, Stay Small
• Side Projects