What I’ve Learned Building Technology for a New Media Company

Editor's Note: This post is part of a technology education series sponsored by Treehouse. In this Q&A series we turn to our very own product team to discuss PolicyMic’s web development and design.

Title: CEO and Co-founder

Twitter: @caltchek

Building PolicyMic has been a challenging and incredibly fun experience. As the head of the product team, I’ve learned how to leverage technology to create a digital media company that reaches our generation with the news that matters to them. As a non-technical CEO, I had a very steep learning curve on web development. In a little more than two years, our small team of engineers and designers have built our own content management system, analytics suite, responsive website, commenting system, and user reputation system. We’ve had successes and failures -- but regardless of the outcome, we’ve learned real lessons from each project. Here are a few of my key takeaways:

1. Get comfortable building your own technology. Some people have told us, “You are a media company, so just focus on what you’re good at: creating content.” That’s the wrong approach.

If you want to succeed as a digital media company, you must have expertise beyond content. You need to be in control of the content creation, design, user experience, distribution, and monetization. Because each domain is so tightly connected, giving yourself the flexibility to experiment and customize each will enable your company to be really successful.

We now have our own content management system, analytics software, and ad-serving platform -- despite the many alternatives available on the market. This custom suite of products are fast, beautiful, and work seamlessly together -- allowing us to solve problems for our users, editors, and advertisers more thoroughly and seamlessly.

2. Focus on products that will make a big impact. When we started PolicyMic, we had a blank canvas. It took a few weeks of failed product iterations to figure out that we needed to focus on products that gave us leverage. The custom content management system (CMS) was our first major project, and has been critical to the efficiency of our editorial team ever since, allowing us to work easily with writers in 73 countries and a data-hungry editorial team.

Another example is how we decided to spend significantly more time on our article pages rather than our homepage. While it may be counterintuitive, the way users find our content means that article pages are loaded over 20 times more than the homepage. That means improvements on the article page would impact many more users' behaviors every day and therefore a more efficient use of the product team's time.

3. Keep a crystal clear roadmap. For us, priorities shift on a daily basis. We are constantly testing new ideas, measuring the success of old ones, and reacting to patterns in how our users want to consume news. With all of this constant change and uncertainty, we’ve learned that it’s important to have detailed product specs before starting development.

This exercise takes time to complete and require significant discipline once you start, but all successful development cycles have started with clear product documentation. Clear specs allow everyone to confidently commit to a plan and execute in its entirety.  

4. Build to scale from the start. In the beginning, we didn’t do this -- and it cost us. On the same day in 2012, we got linked from both Drudge and the front page of Reddit. The resulting traffic crashed the site.

In today’s media landscape -- with 1.2 billion Facebook users and 241 million active Twitter accounts -- media companies have access to massive audiences like never before. Content creators should build to scale from the very beginning. We learned this lesson the hard way, but since learned to always be ahead of our growth.

5. Design is just as important as development. After launching PolicyMic, we worked with a very talented front-end developer who doubled as a designer. A two-for-one deal! Not so fast. While we were able to ship out a product quickly, the design did not reflect the brand we were trying to convey. It wasn’t the developer’s fault -- he wasn’t a designer and we were cutting corners.

6. Put yourself in a position to win. At the early stages, our company often felt pressure to push out a quickly developed MVP (minimum viable product) instead of spending the necessary hours testing and refactoring the product. Everything from development to testing to deployment was always rushed. Result? The products were inadequate.

After a few hard failures, we learned that quality is much more important than speed. Of course, speed still matters. So instead of making a tradeoff, we developed systems that make the painful stuff – like writing tests, QA, and deployment – really easy. In the process, we’ve actually sped up our overall development process without sacrificing the quality our team expects.

Want to build the next best start-up? Treehouse will help you do it.