6 steps to perfecting an open source product strategy

Suppose you have an open source software idea that you want to spread quickly. To gain users, you must make sure your product is both well-made and has all of the right features. You also need to make sure people understand why your project exists and why they should be interested.

Although recent trends in "DevOps" highlight the need for operations and development experience to blend together, seeing development, product management, and marketing ideas merge is perhaps even more powerful. This is the way I crafted Ansible in the early days—and I believe it grew quickly because of that focus.

To achieve high levels of open source software adoption, we not only need to build great software, but we must get to know our users to refine our ideas, and, just as importantly, be able to connect with future users to pull them into the fold. This enables a cycle: Acquiring more users improves the pool of information, which helps continuously refine the product and also continuously improves the rates of product growth.

Product strategy is most about what to build when. It is most effective when it seeks to genuinely connect with and help users, rather than sell something. In open source, we seek first to understand, then serve an audience collectively to build tools we can all share, develop, and use.

Here are six ways to create an open source product strategy that works.

1. Cast a wide net

If you want to get as many users as possible, you will need to build a project that is interesting to a wide number of people. Your potential audience naturally shrinks if you require a particular operating system, distribution, programming language, or software stack. Targetting a narrow "vertical" use-case can also shrink an audience. A program cannot be all things to everyone, but enabling a larger user pool keeps possibilities open, and having more users allows for more growth.

Why is this important? Open source ideas easily expand through social channels—people talk about the tools they like and don't like. Those people who are not in your target audience are immune to the effect, so it helps to make software broadly appealing.

How do we target enough users? Suppose we're developing an infrastructure application that could be very useful in cloud and microservices domains. Although targeting "microservices" might be popular, describing the application in more general terms would get more people to try it out. Mention it as a use case, but define your application more broadly.

A similar scenario would be marketing a slick utility written in Go as a Go application. Although this may attract users from the Go community, it would limit the opportunity to get users from dozens of other programming languages.

We care about casting a wide net because getting more users helps us build better products.

2. Be authentic and informative

Once we have a widely appealing product idea, telling people why they need to try it out is important. Unfortunately, few projects or products get this right.

When looking at the average startup's website, you are probably met with a sea of buzzwords, three adjectives sitting in little cubes, meaningless phrases, clipart of people shaking hands, and a lot of difficulty understanding the purpose of the product. They'll want you to hit a contact form and then have a conversation with a sales person to know what a product really does and upsell you on features you probably didn't know you wanted. The conversation ends with a bad taste in your mouth, no sale, and a lot of wasted time.

If you're looking at an average open source project's GitHub page instead, you'll still often barely understand what a project might be about. You may recognize that it combines the names of three technologies you don't understand, but you'll have little idea of how to use it or what it does. Finding out will require hours of homework to sort out details. This is just as bad. There are troves of amazing projects on GitHub that people never find, because the projects don't seek to market or explain themselves.

When explaining your product to the world, there needs to be a middle ground between the two approaches. Open source products spread best when they are incredibly explicit in saying what they are. Lead with the problem you are solving.

Projects should market themselves with a mix of use cases, examples, and systems architecture. Explain the design of your solution in ways that are clear to an audience without a lot of background, but also include enough detail to answer the questions of someone who does.

Include screenshots and architecture diagrams where relevant. You can include a short video, but also provide written information for those who don't have time to watch it.

Although your goal is to convince people to use your product, you're also trying to help them rapidly understand what it is and isn't. Be upfront with limitations and goals. Trust and honesty is worth tons.

Be transparent. Speak simply but completely. Seek to help educate and influence, but not manipulate.

Now that we have users interested in a product, we'll want them to have a good experience trying out the software and learning to use it.

3. Obsess about great documentation

You need new users to be immediately successful and love your product as soon as they start using it—you don't want them struggling to figure out how to set it up. Therefore, investing in documentation is the most important thing you can do for your project.

If a user wants to try out something with your product during their lunch hour, they should feel successful at the end of it. If not, they will move on and their frustrations will become Twitter rage that discourages other potential users. In contrast, immediate success becomes a "wow, application X is great!" tweet and encourages new users to try it. Do not make users struggle to figure out install instructions—show them what to type at every step and get them closer to the "wow" moment faster.

Think about every experience with the documentation as a chance to either win users or lose them. Realize that users are coming in at different levels of technical knowledge, so don't assume they know all that you do. If the documentation consists only of code-generated, tersely commented API functions, you've already lost them.

Documentation should explain the purpose of your project. Describe why a user should read a section, provide examples, and hyperlink to areas the user may want to explore next. Recognize that some people learn sequentially and others randomly, so provide an index, "see also" sections, a FAQ, and a glossary. Documentation should be enjoyable to read and explore, not an hastily produced afterthought.

A simple tutorial or install guide is probably one of the most retweetable or Hacker News-postable types of content you can make. People will also write their own versions using your guides as reference and post those. Be sure to have content that enables your community to want to do these things.

At this point, we should have acquired some happy users. We can then use this pool of users to help make better a better product.

4. Constantly gather new ideas

Investing in retaining users while they are learning your application results in the next step of the process: feedback. Hopefully you've structured your project to be highly conversational—if not, now is the time to start communicating. You want to know your users well, and especially your contributors.

Use mailing lists, IRC, and webchat to get to know your users. Use surveys, but leave them open ended so you can learn new, unexpected things. GitHub is okay for code, but maybe it is not conversational and friendly enough to really get to know your users.

An important skill to develop is intuition for what users' day-to-day life is like. What features do they need? Which features do they only think they need, but really don't? What features do they not know they need, but would be blown away by?

Rather than talking to a handful of users (e.g., a paid customer pool), you have the opportunity to talk to a potentially huge amount of people to better understand your market space. Your users already care about your software and want to make it better, so take advantage of that opportunity.

In gathering ideas, we've probably noticed a lot of ideas that conflict. Many users want to use our product in ways that we don't intend. Whereas many proprietary products might try to limit scope at this point, because of the powerful effects of an open source ecosystem, we'd really like to accommodate those users. We realize that our product is starting to be a community-owned entity. We should find ways to accommodate them, where it makes sense.

5. Keep options open with plugability

Focus is important, and trying to please everyone may result in a feature-bloated product that is hard to learn. Disagreement is common in open source projects. Forking actually is pretty rare, but there are a lot of moments when someone might pick another tool over the one you built.

Keeping architectures modular is an incredibly useful way to avoid this. When a dispute comes up on a mailing list or a GitHub ticket, you can say, "I'm not sure I'd want this as a core feature, but what if I made a way for this to be a plugin?"

Plugins are pretty much one of my best secret tricks. Many of the most successful web projects seem to have extremely strong plugin ecosystems. At a lower level, programming language library collections essentially are plugin ecosystems.

By keeping options open with plugins, we've kept users. These users can help share our product with others, and they may contribute with bug reports, patches, documentation, or other things down the road. Although we've transitioned from an initial idea to more servant leadership, we have to recognize that this project is still something we've created and nobody can know it better than us. There are still places to go that our community might not have seen yet. So let's keep imagining...

6. Dream about reachable futures

Not all the data will come from your users. Your own inventiveness is why the project got started, and it will help orient everything that comes. Constantly thinking about all the possible things you could do or all the possible contributions you might get is useful.

Cultivate a "what-if" mentality that explores possible avenues. What near-term features could you build, and what other near-term features might those enable if they existed? What long-term areas might you like to reach, and what are the near-term features that have to be built before you can get there? What is the opportunity cost of working on those features instead of others?

Sometimes the slightest change in a project can open a new sea of contributions and excitement.

Balance time spent on serving your community with time exploring your vision for improving it. You will probably get to a place where you literally dream about new product features that will help users you've met. Although I've woken up with bizarre ideas, I've also implemented quite a few of these.

Where to go from here

At this point, I hope you've noticed that the cycle of communicating and helping users is all connected and self-reinforcing. Making the right products is a function of everyone building and planning the product being a part of the same community.

Having unified product management, marketing, community, and development is how we all start out when creating a small project, and as companies grow, it is important to realize going back to that mentality—even as we specialize—is still how things work best.

Seek to meet people, learn about them, help them, and enable surprises. That's what open source is all about.

Learn more in Michael DeHaan's talk, Demystifying Open Source Product Strategy, at All Things Open 2017, which will be held October 23-24 in Raleigh, North Carolina.