Building software products starts with an idea.
A product idea can go a couple of ways depending on your company’s development culture. The idea could show up in a list of requests sent to someone higher on the food chain who will decide whether it’s a good idea. Or it could be an email to a specific engineer, pleading her to “PLEASE BUILD THIS IDEA”.
At Doximity, we develop ideas differently. We work towards what we call "MOFO" goals.
MOFO? Seriously?
Yes. MOFO is short for My Objectives For Offsite. What did you think it stood for?! A MOFO goal is:
- Strategic: It should roll up into larger company goals
- Achievable: A needle that can be moved in 12 weeks time
- A stretch: No sand bagging here. We shoot for the stars
For example, a MOFO goal could be to launch and sign up 100 people on a new product. Or it could be to increase conversion on our registration funnel. Or it could be the less sexy, yet still important, task of reducing our page load time by 25%.
All MOFO teams set three MOFO goals per quarter to guide development priorities. We’ve found MOFO teams operate best in small, 5-10 person teams responsible for different products. Each team contains a group of engineers, a product manager, a data scientist, a designer and a QA engineer.
So how do we decide which three goals to focus on?
- As a team, we collect data, projections and ideas to discuss how these might fit into potential MOFO goals.
- Once the team has reviewed and discussed options, the product manager establishes baseline and goal numbers for each finalized MOFO.
- The leadership team reviews how the proposed MOFO goals align with company goals. Some ideas die here, and that can be a good thing.
Iterate / Implement / Iterate
MOFO teams work throughout the quarter in two-week iteration cycles. Our goals shape and prioritize the features in each iteration. While some traditional scrum roles emerge, the size of our teams encourages us to look beyond our functional specialties. That means the whole team has ownership and visibility into all aspects of development. For example:
- Designers present on the potential variations they’re considering and get team feedback on which to use.
- Data scientists share insights into the different models they’re testing and take suggestions on future model tweaks.
- Engineers review and suggest product flow alternatives to help speed up user interactions or improve experiences.
As the team ships features, we showcase them on the all-hands weekly call with a summary of how the features impact the business or user experience. We also show how these features move us closer to reaching each MOFO goal, providing full transparency on development status.
The MOFO goals keep us focused but provide room for minor strategic shifts and creative solutions. Our 2 week roadmap can change based upon learnings from earlier tests.
The results are in...
At the end of the quarter, we meet at a company-wide offsite to discuss results. Did we meet our goals? How? We typically present on things like:
- Split tests and variants. What did we test and how can we generalize those results?
- New features that distinguish our products. How are we staying ahead of the competition?
- Ways we reached or missed a goal. What if we had done things differently?
Presenting our results to other MOFO teams helps us to cross-pollinate ideas to improve upon the following quarter.
MOFOs allow us to try new ideas, to evaluate them and to decide whether that idea-turned-product is worth pursuing. This keeps us honest; if a product isn’t really working out after 3 months, should we keep trying? If something works, could we refactor our code to make it work with fewer errors? If it’s working well, how could we invest more to make it really shine?
Software development cultures come in different shapes and forms. Building product starts with an idea, but ideas can often falter without a process and cadence to guide them into production. For us, MOFO goals help empower teams to prioritize ideas and shape them into great products.
