A few weeks ago, we were invited by the Knight Foundation to join with other Knight News Challenge winners and discuss the various successes and challenges faced by our organizations. It was a terrific opportunity to recognize that many start-ups and small organizations go through nearly identical growing pains. The meeting was more than group therapy; our sessions provided some key insights into how different teams have tackled similar problems in their own contexts.
As to our context, we had just released FrontlineCloud as a beta product. Since then, the team has rejected my proposed tagline, "FrontlineCloud: It's not just vaporware!" Yes, I made that pun.
In many ways, FrontlineCloud represents the largest product release in our organization’s history, at least in terms of potential users and options for creating features. It certainly required our team working at full speed and overcoming a number of obstacles, both foreseen and unforeseen -- the known unknowns and the unknown unknowns, if you prefer I get Rumsfeld-ian about it. It was also a lot of fun. We thankfully had our award-winning desktop application as a strong template to build from, and then applied our vision of what the world’s simplest, most connected SMS platform would look like.
I think we’ve built a great app in the end. It’s nowhere near our final vision (see one of my points below), and we are working quickly to smooth out our user experience. But it meets all of our primary goals, which were:
- Build a web-hosted application with more ways to connect than any other SMS service;
- Create a product that is wholly user-centered, and that upholds the ethos of our company in expanding the ways that our users can reach those they care about the most;
- Design, to the extent possible, an app that anticipates things we know the user needs, and build in ways to measure behavior for the unknowns;
- Plan for our future roadmap in our initial release; in other words, don’t create code that will need to be overhauled to meet our future goals, which are dramatically larger than the current beta application might suggest.
As product manager for FrontlineCloud, I thought it might be helpful to share some insights on product development from a small organization’s standpoint. These are all lessons jointly heard at the Knight meeting among many of our peers. Some of these lessons came from past experience, others came from starting production on FrontlineCloud, and others were gut feelings that thankfully panned out nicely. I suspect any small company will have a healthy mix of these factors when starting product development.
Here are some of our insights:
Get Out of the User’s Way
We, along with many of our supporters, often first think of FrontlineSMS, and now FrontlineCloud, as a means to communicate. But that’s not how users view the platform at all. They communicate for a reason, and often a remarkably civic-minded one. Whether our users are monitoring elections, improving service delivery, connecting people to important legal services, or providing critical information on reproductive and sexual health, they are using SMS in a professional light to achieve a goal.
To the extent possible, technology should not be the purpose or end goal of an interaction, it should facilitate some other interaction as easily and humbly as possible. Our CEO, Sean McDonald, couldn’t have been clearer on this point, and he’s right. Communications facilitate a higher goal, whether we, the communicators, are just checking in on a friend or starting the next major civil rights movement.
Your First Release Cannot Encompass Your Entire Vision
One of the trickiest challenges early in the development of FrontlineCloud was determining what a releasable product would look like. Our vision exceeds this beta product, and that’s fine. But the beta product needed to achieve the primary goals I mentioned above without precluding the product we ultimately envision. Some refer to this as Minimum Viable Product (MVP) -- we preferred the phrase Minimum Marketable Product, which we felt encompassed user experience more completely than MVP might imply. Regardless of the terminology, the first version of your product will never be perfect; the trick is to figure out how to use it to lay the groundwork for your grander vision. Usually this means it is feature-light and accessible. It’s about crafting the core experience, with nuance and additional features layered in over time.
Product Owner and Project Manager Need To Be Distinct Roles
This was one of my favorite concrete lessons from the Knight conference, because it distilled a point I’ve been trying to articulate for awhile. These job titles vary across organizations, but there is a basic formula of 3 key staff needed for application development organizations with limited staff capacity. This was described most succinctly by my colleague Brian Boyer from NPR / Panda Project. To roughly paraphrase, the 3 key staff are:
- your talent - these are your developers, responsible for creating your product; most organizations use some type of ticketing system to assign tasks to the talent, who then spin that straw into gold
- a product owner who is responsible for daily stand-up meetings with the developers, quality assurance tests to determine when a feature is ready for release, and understanding the big picture so as to ensure the application’s architecture doesn’t preclude feature releases in the future
- a project manager who is responsible for being the user’s advocate; the person responsible for insisting that features be as smooth and well-designed as possible, eternally harping on UX and UI; and for creating the product roadmap so that bigger features and design issues are addressed in an agreeable priority order
Ultimately, your product manager and product owner should spar -- hopefully in a friendly way -- over what a user ultimately needs and what is technically feasible, working with your talent to come up with clever solutions and workarounds to sticky problems.
Many groups early on, either due to inexperience or lack of resources, attempt to combine the product owner and project manager into one position. We were no exception. My own technical prowess is extremely limited, so acting as a product owner was leading to a lot of confusion and long conversations in which our developers patiently explained technical elements while presumably doodling dagger-filled, stick figure effigies of me. It was a waste of time, and our productivity jumped immensely when we hired a business analyst who could handle more of the technical product elements. It also freed me up to work more on our product roadmap, laying out a much clearer path for finalizing a beta version of FrontlineCloud.
At the Knight meeting, many people said that acting both as product owner and product manager leads one role to suffer. Either someone gets excited about the technical aspects and forgets that someone needs to actually use the application in a timely manner, or they focus on user needs and make unwise, unwieldy demands on the technical team with no one to balance these demands.
Boyer acknowledged that a small, 2-person startup may not be able to get these three positions in place right away, but that companies should strive to reach this balance as quickly as possible.
Have a Solid User Support Plan
We worked with our Operations Manager, Cathryn Stickel, to create a strong user support plan for our beta launch. We actually launched our product, a new website, and a new support platform all at once. That might sound crazy, because it is! But hey! It worked! And a significant part of the success was having a solid plan for user support in place. Namely, cover user requests to the best of our capacity, and distinguish between tech questions and bugs that only developers can answer, and all of the other questions that a first-line support team can answer directly. Our first effort was imperfect -- we’re still iterating -- but it was a good plan to start with and led to addressing some critical fixes early on. It kept our blood pressure low and meant our team could largely enjoy the launch afterglow without suffering a lot of bug-related stress.
We continue to have insights in the product development process -- in fact, they're accelerating now that we're moving out of beta. We'll plan to share additional insights here as we learn them ... and would love hearing points of learning from our community as well.