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?

  1. As a team, we collect data, projections and ideas to discuss how these might fit into potential MOFO goals.
  2. Once the team has reviewed and discussed options, the product manager establishes baseline and goal numbers for each finalized MOFO.
  3. 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.

As we did last year, we'd like to share tools we found useful in 2016. This is by no means a comprehensive list, simply some of the highlights.


by: Julio Monteiro

In the beginning, there was grep. Then ack, a pure Perl script that made searching faster compared to grep. A few years ago we got The Silver Searcher (ag), a tool built with C namely faster (and "33% sorter") than ack. Finally this year, ripgrep (rg) was launched, built with Rust and until this point the faster command-line utility for searching plain-text data sets around.

Other than being fast, its regular expression engine uses finite automata and guarantees linear time searching. Searching across huge code repositories is fun again. At Doximity, searching across all our private code repositories takes less than a single second. Give it a try, I'm sure you're going to like it.

Giphy Capture

by: Ben Fischer

Giphy Capture is a tool to take your pull requests to the next level. Make a 20 second recording and embed it right into the PR description. This helps reviewers understand the intention of your change faster. If anyone does a git blame in the future and comes back to your pull they'll see with their own eyes that your code was working. Alternatively you can also use LICEcap mentioned next.


by: Jaymes Waters

Licecap is a dead simple gif creator. It records & saves a gif from a selected area of your desktop. It has been an invaluable tool to create quick, simple animations to share with product managers, quality assurance & other developers.


by: Mujtaba Badat

Anyone that spends a lot of time analyzing data knows how much of a pain it is to organize queries, build visualizations, and keep those visualizations fresh. Re:dash does all of that and more by allowing you to write SQL and turn it into shareable dashboards. Key metrics are the compass that guide entire teams in the murky waters of developing new products. By making dashboards easy for everyone, re:Dash helps teams never lose sight of what matters most.

by: Marcus Derencenius

DevDocs is a web app that provides documentation for many languages and frameworks. The kicker is that it provides offline support. It is super fast and gets updated frequently.

What tools did you adopt in 2016 that helped you get work done? Follow us @dox_engineering if you'd like to be notified about updates to this blog.

Funneler is a simple gem developed to: group different pages from one or more apps into a cohesive flow.

At Doximity we want to ensure our users get the most out of the medical network they're joining. In order to make that happen, we provide a personalized onboarding experience for each user. Our customization spans the device the user is on (web, mobile web, and our mobile applications) as well as other variations such as taking into account how or when a user is registered. Of course accounting for all these variations is easier said than done.

Funneler provides us the simple tool we need to make that happen:

  1. It groups pages together via a funnel_token parameter
  2. It is light weight - meaning there is very little overhead to modifying a controller to use that parameter when present, or fallback to a default behavior otherwise
  3. The funnel_token is not dependent on any datastore
  4. And thus it can link pages across different applications
  5. It is simply a link, and therefore can easily be used in emails

Let's take a look at how to use funneler. For a moment, pretend your application has two pages you want your user to see /welcome, and /setup before landing at their final destination /home.

Naturally the simple solution would be to setup each controller/action to link to the next page. However, as you know that is brittle, and certainly can't be customized per user without a lot of code. This is exactly what funneler now provides:

funnel = ['/welcome', '/setup', '/home'])
redirect_to funnel.first_page

This will redirect to a route like /welcome?funnel_token=...... The funnel_token is a JWT token encoded with a few simple pieces of data:

  • routes - the array of routes to funnel a user through
  • current_page_index - the current index into the routes array

On subsequent requests, any controller can read the funnel_token and redirect to the next_page such as:

funnel = Funneler.from_token(token: params[:funnel_token])
redirect_to funnel.next_page

The funnel simply builds a new token which has an updated current_page_index, and returns the route at that index with the new funnel_token in the query string.

Of course this is a simple example with a static set of routes. However it shouldn't be hard to imagine customizing the behavior by dynamically generating the routes given different inputs and parameters. The best part about using funneler is that creates a clear separation between controller behavior, and the business logic determining which pages should be included in the funnel.

Funneler has been open sourced on GitHub - feel free to contribute!

Developer happiness is what brought me to Ruby in the first place. And of all the new compiled languages, Crystal is the only one that shares this value. The syntax and idioms are entirely Ruby inspired.

Although Crystal looks very similar to Ruby, there are big differences between the two. Crystal is statically typed and dispatched. While there are no runtime dynamic features, the compile-time macros solve many of the same problems.

In this session, we’ll take a close look at these differences as well as the similarities, and what Ruby developers can learn from this exciting language.

For more videos, visit our new Videos channel.

Observables are a way to model push-based data sources such as DOM events, timer intervals, and sockets. Ben Fischer walks us through properties of this model in depth including how to create, filter, combine, and transform streams. He will also highlight situations where using Observables in web applications makes the most sense.

For more videos, visit our new Videos channel.