Keep reading for a walk-through of our development process from alpha to full product launch, and reflections and lessons learned.
For over a century, newswires have distributed their stories via RSS feeds, teletype machines, and even The Pony Express. What do each of those mediums have in common? They send stories out into the ether, and are difficult to measure.
In late 2021, with stories from our newswire being published by over 700 outlets every month, we realized how crucial it is to track the performance and reach of our coverage beyond anecdotal feedback. Hence began an 18-month process to ensure we didn’t fall victim to the same challenge that has plagued newswires for over a century: publishing stories without a clear feedback loop on what resonates with our audience.
Solving this problem is crucial to our success; today, we provide a free newswire to over 2,000 publishers nationwide. A content studio subsidizes the newswire, which requires us to prove the value of running stories on the Stacker Newswire, and our analytics platform has become pivotal in ensuring we can optimize the value we provide to customers on both sides of the marketplace.
Keep reading for a walk-through of our development process from alpha to full product launch, and reflections and lessons learned.
To begin, we created a pixel that would be attached to all stories that ran across our RSS feeds and in our publisher-facing portal, Story Hub. This approach provided us with an extremely low cost of entry, but it wasn’t scalable, as it required engineering resources to export the data from the database manually.
There was also no connection to our CRM, which meant we had a giant list of URLs but no way of easily identifying whether the syndicated stories (“pickups”) were from one of our publishing partners. It served as an important foundation, but there was more to do.
Next, we built a web app on Heroku that tied into our Airtable CRM and allowed us to run a series of reports that sliced the pickup data by story or publishing partner. During this process, we pulled together a small group of Stacker employees to raise problems they were looking to solve and to provide regular user experience feedback. We kept our focus narrow and said no to requests that might distract us from core functionality.
As a result, the system was intuitive and easy to navigate without feeling overly burdensome. Based on feedback, we also added a series of alerts; for example, whenever a publisher hasn’t picked up a story in 30 days or whenever a story has slow pickup velocity. These alerts now trigger our team to reengage a publishing partner or consider republishing a story or rewriting a headline.
However, we didn’t spend enough time considering the eventual scale of the product and suffered from outages and slowness as the database grew larger and larger.
Once we had validated the product’s desirability and feasibility, it was time to make it viable long-term. We built an analytics platform for scale on DigitalOcean using NodeJS and Postgresql. It integrated seamlessly with our CRMs (Airtable and HubSpot) and CMS (Drupal). We also integrated a third-party authentication service and developed training materials both for our in-house account managers and our clients and partners accessing the platform.
Lastly, we began to separate each user persona’s experience and features.
There were a lot of lessons learned throughout the project—some new and some reinforced. Here are a few key takeaways for product managers navigating the transition to a successful product launch.
When you’re operating a 24/7 newsroom, uptime and reliability are critical. You need to spend countless hours architecting, budgeting, and reducing risk for new tech stack updates. You must think about changes to workflow, regression testing, critical security patches, and the list goes on. Is it really worth it to do all that when you’re just testing a new idea that might not work?
Once we got to the beta phase, we built the analytics platform outside our standard tech stack. This allowed our primary developers to stay focused on the production-ready platform and let a separate team to go all-in on building a system we knew would get us to market quickly, albeit with a potentially limited shelf life.
It’s a gamble we were willing to take, and if we went back in time, we’d likely make the same decision.
From the beginning, we knew this platform had the potential for massive scale and could—over time—satisfy a myriad of use cases and user personas.
But we needed to focus. So the product team said no often (and politely).
In our beta version, users regularly asked to include certain features. But those features brought risks to the performance of the database. It also took our small team’s focus away from identifying the specific data points most helpful to our users.
And when we launched our customer-facing portal, we picked a single persona: the power user. While we would have loved to build exec-level dashboards for stakeholders and budget holders, we knew it would stretch us too thin. We would need to add more helper text, context, account and payment information, etc.
As we already mentioned, measuring the distribution of a newswire is an age-old problem that many people have worked on. Before we built anything, we explored off-the-shelf technologies that we might be able to buy, but none fit our use case.
We set up a series of conversations through the News Product Alliance Slack, then took inspiration from some of the top minds in the business, like The Texas Tribune and ProPublica, to understand how they approached the problem. At no point did we try to hide what we were working on, and we saw the benefits of sharing our lessons—and fears—with others.
While design and user experience provide the first impressions of a product, the technology “under the hood” is equally critical and can either help you be wildly successful or bring down your entire system. Our technology partners at Dentzau, LLC helped us think through the most cost-effective and efficient solutions.
A whole new series of challenges arose when we started planning the transition from beta to launch.
Each of these items took time and money. Had we not planned and budgeted for each of them before we launched the project, we could have quickly gotten in over our heads.
Looking back, we didn’t make a hard cutover from our beta product to our launch product. We kept both running while we replicated functionality in the launch product (and, of course, culled features we learned we didn’t need).
But that meant supporting two systems on two different architectures with two different development teams. It required teamwork when things went wrong (i.e., which system was responsible?) and extensive coordination when making critical updates. We also saw our internal users getting confused as to which system they should access for what.
So be confident in your success. If you’re ready to transition, go all-in and shut down legacy systems with the same vigor that you launch new systems.
As we look out over the next six months, we’re excited about our roadmap. Here are a few things we plan to implement:
As always, we'll continue listening to our customers and improving the product to ensure we're delivering them a best-in-class solution.
As part of our commitment to supporting nonprofit newsrooms, we plan to scale the program to even more newsrooms in 2024.
All our content is written and edited by humans. But we believe that AI can be used to help with production and research tasks. Here's how we're...
Stacker uses creative business models and technology to upend the traditional newswire. Read on to see how we are approaching the challenge.