Finding an Opportunity
In the summer of 2016, most of our engineering team was involved in a months-long initiative to resolve our technical & infrastructure. Given that limitation, we explored other opportunities where we could provide value to our customers (or at the very least, learn something about how our product can better meet our customers' needs). A combination of circumstances led us to test an improved mobile experience of TORCHx:
We already had a hunch the current TORCHx mobile experience was problematic. We didn't offer a mobile app, so all our mobile touchpoints were through our responsive website, which suffered from a cluttered interface.
TORCHx was acquired by Web.com the previous year, and this interface was a symptom of its pre-acquisition mobile strategy: replicate the entire functionality of the desktop experience in the responsive mobile site. This resulted in many usability issues with the mobile site, which we hypothesized was a cause for its low usage (10% of traffic). Armed with this knowledge, we wanted to validate some of our assumptions by interviewing customers. We spoke with real estate agents that had recently used the mobile site, and those that hadn't used it in months, and learned:
They weren’t tracking conversations that happen on-the-go because manual entry was inconvenient in our mobile site
This research helped frame some issues with the mobile site, but we knew that to truly improve on the value of the mobile experience we had to release something and measure its impact. Now the question was: what do we release?
Finding a Minimum "Learnable" Product
Our goal was to put something in the hands of our customers and learn from it, whether it proved or disproved our hypothesis. The next step was to generate ideas, align on what we wanted to test, and come up with a more focused hypothesis. I facilitated a design studio with participants from Product Management, Design, Product Marketing and Engineering to ensure everyone was bought-in, engaged, and involved in the product development process. We generated ideas that fell into different buckets:
We voted and aligned on testing a notification-driven experience that would alert agents of new leads and incoming messages. Our gut reaction was to design & build a lean (read: maybe only 1-2 features) mobile app, since that was what our customers were asking for, and what we were losing sales to. But since our goal was to test our hypotheses and learn about our customers, we wanted to build something faster, and less expensive to maintain and update. Mobile apps also pose an entirely different problem, adoption, which wasn't part of our hypothesis or problem. So, we moved forward with a thinner slice, and opted for a leaner, responsive site.
A New Hypothesis, and Several Design Reviews Later
As a product team, we continued to slice thinner and thinner until we arrived at a testable hypothesis:
Clients using the new mobile experience respond to more texts in less time, and spend more time in the CRM than those without the new experience.
...And This is When we Failed
But we learned! A lot.