How we Started Building the Right Stuff Faster at TeachBoost

8 min readOct 28, 2015

There are countless blog posts and resources online telling the world how to build software products, but due to the unique environments and constraints in which teams operate, there is no such thing as a one-size-fits-all software development process.

I’ve learned a great deal about product management by digesting posts (links at the end) by teams who write about their product development process and simulating these processes in the context of our team at TeachBoost.

So, in an effort to contribute to the conversation, here’s how we build stuff at TeachBoost.

The Old Process

In the early days, anyone at TeachBoost could submit an idea to our “Product Ideas” Trello board (shown below). The product lead reviewed each idea (a card), categorized it (using labels), and then moved it into the appropriate feature set bucket (a list) or archived it for future consideration.

Next, the product lead would prioritize the ideas based on each card’s label — for example, “high priority,” “frequently requested,” “high revenue potential”. At this point, the ideas had become feature requests and were moved over to the development team’s roadmap to kickoff development.

While this model worked in the early stages, over time three factors rendered this development approach problematic:

Our team was growing
We kept learning more about the problems facing educators
Our users’ customized implementations were becoming more complex

A Growing Team Calls for Increased Transparency and Better Communication

In any organization, the sales and marketing teams need to know how the product is growing over time so that they can prioritize market segments, aid in customer discovery, and communicate the vision to potential clients. The customer success team must also be able to aid in discovery, effectively respond to requests and feedback, and understand how they’ll address user needs both today and in the future.

When the TeachBoost team consisted of the three founders, everyone contributed to product development and product vision. Internal communication was effortless. With a growing team including non-product-focused employees, however, we realized our product vision, roadmap, and prioritization process were not transparent and well-communicated internally. Our communication system needed an upgrade.

The More You Talk to Your Users, The More Features You’ll Want to Build

By focusing on feature ideas rather than user needs or jobs to be done, you can quickly fall into the trap of feature creep, a frankenstein product of pieced-together requests, or the dreaded “Product Death Cycle.”

Because our “template” to submit product ideas was just a blank Trello card, anyone could submit an idea — like “add a hashtag feature” — with little details. That left many important questions unanswered:

Why does the user want this feature?
What problem is this addressing?
Who is this for?
How important is this feature?
How do they currently solve this problem?

Without requiring answers to these questions, our team wasn’t prompted to tease out the problems and root causes when discussing features requests with existing or potential customers.

A Balance Between an Open and Closed Roadmapping Process is Essential

Completely closing off your roadmapping process to people outside management and the product team can create walls between decision makers and customers. On the other hand, a completely open process can cripple prioritization, leaving you with a big stack of ideas and no idea what to do next.

Our open ideas process required little more than a one-line description, producing an overflowing Trello board that quickly became unmanageable to prioritize — when you spend hours every month trying to figure out what each idea card means and moving it to the proper list, how do you make the time and mental space to identify trends or themes? Without a clear understanding of the product’s vision, function, and value proposition, how can you prioritize the most valuable product ideas to pursue?

In our old process, the product lead was overburdened, development felt they were getting too many disparate projects handed over, customer success wasn’t getting their users’ needs met, and sales and marketing were struggling to contribute to our product vision.

Goals for Our New Process

We set out the following goals for redesigning our new process:

Keep the process open to input from the whole team
Stay in the “problem” space longer and dig into root causes
Focus on user needs and the goals they are trying to accomplish
Increase transparency of the prioritization rationale
Improve internal communication of our product’s vision and roadmap, as well as how our product team is helping the rest of our team achieve our goals
Better allocate our limited resources to ship the right products faster

Step 1: Prioritize Challenges Facing Our Users and Our Team

The first step in our new process is to prioritize the challenges our users and internal teams face as they work to accomplish high-level goals. We do this via our quarterly Product Council.

Every quarter we hold a Product Council meeting with the TeachBoost teams (Customer Success, Sales & Marketing, and Development).

With a lean team and a growing business, it is important to build in time to take a step back from the day-to-day; think about goals, strategies, and challenges; and provide a forum where everyone’s voice can be heard.

In the Product Council, each team has the opportunity to:

highlight the greatest challenges that faced existing or potential users over the past quarter
surface the team’s recent challenges
report on team goals and challenges for the next quarter
make a case for why the product team should tackle one of their challenges over the next quarter

The product strategy team then prioritizes which team challenges to work on, based on the following criteria:

Impact on our team and users
Fit with our product vision
Current resources
Time of year (as an edtech company, we have to be sensitive to the flow of the school calendar)

The prioritized challenges are added to the Roadmap Trello board. Unprioritized challenges are moved to a “tabled” list, but are not archived or hidden. This way, our teams can continue building stronger cases for prioritizing them in future quarters.

For example, streamlining the complex account setup process for our support team (the “challenge”) is vital to scaling our ability to deliver the bespoke implementations our customers need. However, due to the cyclicality of education, this problem won’t resurface until the summer, when our new district partners get ready for the school year. In the meantime, the product team can focus on more urgent challenges and the support team can continue building a case for streamlining account setup at the next product council.

This first step enforces a focus on long-term vision and solving the most important problems.

Now that our team is onboard with the challenges the product team is tackling over the next quarter, the next step is to prioritize the user needs and minimum viable feature sets that address these challenges.

Step 2: Prioritize User Needs and Minimum Viable Features

There has been an encouraging trend of product teams roadmapping based on user needs and problems rather than features and solutions.

Maintaining an open sourcing process, focusing on user needs, and spending more time in the problem space are the keys to building our roadmap.

Paradoxically, these activities enable us to the ship the right products faster.

For you trendy design-thinking folks out there, at this point we have merely figured out the prompt, or the “challenge.” Now it’s time to put on our divergent thinking caps, start empathizing, and define the user needs for our prioritized challenges.

To begin, we gather as many observations and as much evidence as possible from our internal teams, and aggregate that with product or support data, interviews, and notes from customer support and sales conversations.

After synthesizing the evidence collected, we define the problems on Trello cards by answering the following questions:

What is the problem or need?
Why is it worth solving?
Who is it for?
How important is this user need (rate 1–10)?
How does the user currently solve this problem?
How satisfied is the user with the current alternative (rate 1–10)?
What are some potential solutions or other considerations?

In Dan Olsen’s book The Lean Product Playbook, Dan does a great job of explaining a technique for prioritizing user needs by mapping out the importance of need vs. satisfaction with current alternatives (shown below). We like this technique, as it builds clarity and transparency into the prioritization process and keeps the team focused on working to create the most value.

Image recreated from Dan Olsen’s The Lean Product Playbook

With prioritized user needs, we now shift to brainstorming solutions and creating user flows, wireframes, designs, specs, or even prototypes. Throughout this process, the engineering team provides input around the capabilities of our application architecture, accrued technical debt, and the resource intensity of the proposed work.

Using these tangible assets (designs, prototypes, etc.) both internally and externally, we test, elicit feedback, and iterate. We’re also able to further refine the user need definition, incremental value provided, resource intensity, and definition of success.

Finally, a quick ROI analysis (Return/Investment) is done using another of Dan’s frameworks, mapping each solution’s return (customer value) vs. required investment (shown below with numbers representing the priority rank of the section).

We don’t treat either of these prioritization calculations as an exact science. Ultimately, the exercise keeps us focused on maximizing customer value and minimizing investment by breaking things down into minimum viable feature sets.

A preference for minimum viable feature sets enables efficient use of limited resources, increased shipping velocity, and a shortened feedback loop.

Step 3: Build and Validate

Finally, the engineering team takes the lead and starts building.

To enable a seamless transition, we’ve involved the engineers in each step of the process, documented all of the work in defining and clarifying the problem and solution on the Trello card, and providing the support of the product team where needed, especially in user testing.

Our testing and beta sites allow for rapid deployment to limited sets of users. Smaller features or fixes can move quickly into production, while larger changes can be tested more deliberately.

Although we have time for testing and refining, time for major iterations of these solutions is not built into the quarter. Since our roadmap is based on user needs and accounts for users’ satisfaction with current alternatives, if we ship something that doesn’t meet the user’s need, it will resurface in the next prioritization cycle.