Bookings: calendar & schedule blocks

Challenge: adopting new technologies

In December 2018, a new editor came to WordPress: Gutenberg, a block-based, Javascript-driven editing experience.

Gutenberg fundamentally changed how users would edit content in WordPress, which WooCommerce and Bookings are built on, and that presented a challenge for our team: it would take a while for the majority of users to adopt Gutenberg, and we needed to support the wide range of existing options for our products both with and without Gutenberg.

We knew that we couldn’t make any of the existing parts of Bookings dependent on Gutenberg or risk alienating loyal customers, but we also knew we couldn’t wait to get started with Gutenberg.

Solution: use it for new features

To both dig into the new technology and avoid disruption for existing customers, we determined we’d use Gutenberg to build new features that were not yet available with Bookings. That let us experiment with a new technology, and also build something that would add value for users, rather than creating a problem for them.

It also allowed us to test a couple of hypotheses we had around Bookings customers:

  1. Based on qualitative research conducted for Google 2-way sync, we identified four profiles for Bookings customers, each with slightly different needs. We believed we’d need to deliver different flavors of Bookings to different segments, and wanted to test whether offering features as an add-on (vs part of Bookings) was effective.
  2. Monetization was a focus for the division, and our Customer Survey research suggested that Bookings customers may have a greater ability to spend than other customer segments. We had a free add-on for Bookings, but not a paid upsell. We wanted to see how lucrative this might be.

Results: a successful launch

WooCommerce Bookings Availability launched as a paid add-on in Q2 of 2019, to positive response from customers. It was the first paid product we launched in three years.

WooCommerce Marketplace Suggestions

Challenge: converting free to paid users

WooCommerce, the core plugin, is free, and is monetized via payment partnerships and extensions. In December 2018, we dug into usage data to understand how well we were monetizing the base of WooCommerce users with extensions.

We found that only approximately 30% of active stores were using paid extensions, and that stores that used extensions were, in general, somewhat more successful. Store were likely to add paid extensions either right off the bat, or when they reached certain success thresholds in monthly or total sales. This suggested that some store owners knew what they wanted at the get-go and bought it, while others waiting until they had some proven success to invest in additional website features, which we validated with qualitative research.

From this data, I hypothesized that more stores could benefit from paid extensions, but weren’t aware of their options early enough in their journey.

Solution: inform users about paid offerings within the product

When a users sets up WooCommerce, there were a couple of ways to discover paid offerings:

  1. Within WooCommerce, users could click on to the ‘Extensions’ navigation item, which meant they knew the term and that it could solve their problem
  2. Outside of WooCommerce, users could Google and potentially end up on WooCommerce.com

While these were strong discovery channels, they required a heavy lift on the users part, both in knowing where to look and what it was called.

A users journey from starting setup to being a successful user with a paid product had a lot of potential drop-off points:

I reviewed on-site and in-product data and created a model to determine where our greatest leverage point was – where could we add something to educate users about their options? Based on the data, I determine that in-product suggestions on other core screens were our biggest opportunity.

I advocated for this opportunity with our leadership team, shifted our development teams priorities to allow us to focus on it, and secured a designer to help us think through solutions.

Results:

When the feature was initially included in the beta release for WooCommerce 3.6, there was strong feedback from developers in the open source community about one of the placements – they felt it was intrusive on the screen. In response, we remove that placement, made opting out of suggestions more obvious, and wrote a blog post for our developer audience explaining our rationale.

The experience was a good lesson in the importance of engaging the developer community, and planning communications explicitly for them.

After we adjusted for the full launch, we received no negative feedback from store owners. Within the first month of launch, this feature became the #4 revenue-driving campaign for the Marketplace.

Bookings: Google 2-way sync

Challenge: top requested feature staying untouched

For more than a year, the most-requested idea from our customers – that they could sync their bookings to Google Calendar – was sitting on the ideas board, untouched.

There were a few main reasons:

  1. Building this feature required a deep knowledge of the Google Calendar API and potentially re-architecting Bookings, which as an older product that most of the team hadn’t built in the first place. We didn’t know what we didn’t know.
  2. From comments by customers around this request, we knew there were three potential needs: a store owner syncing their store calendar to their personal one (one to one), service providers syncing the relevant parts of the store calendar to their personal calendars (one to many) or a combination of both. We knew we didn’t have a rich-enough understanding of our customers to decide between these needs.
  3. Because of the complexity of the project, other ideas kept jumping the queue.

At the time, our process for tackling big features was to assign one or two developers to dig in and just start coding. That meant when they were pulled away, the project stopped, because no one else could jump in.

For this feature, we needed a different approach.

Solution: new processes, better information, more collaboration

Working with an engineering lead and two designers, we defined a new approach for this feature:

  • Developers started with technical research sprints, where each developer considered a different technical approach for the problem and created a proof-of-concept for that approach. When completed, they shared their findings with the team. That meant we had a better understanding of what we didn’t know, and that knowledge was shared across the team.
  • Designers started with a qualitative research sprint. With a basic foundation for our target customer based on the Customer Survey I ran, we recruited and spoke with 20+ customers and potential customers in one-hour interviews. From there, the designers built four detailed user profiles for Bookings customers.

Based on this research we made a few key decisions:

  1. We focused on the one-to-one need, because it was simpler and applied to one of the profiles.
  2. We decided we’d ship the feature after the holidays, because we didn’t have the time to finish development without bumping up to the busy holiday season. This allowed us to practice shipping quickly on another feature.
  3. Because we had rich qualitative data, we chose to simultaneously work on related features that would lead to a more complete release.
  4. We started working in weekly sprints, including weekly demos from the team on all issues completed that week. This allowed us to stay aligned on the scope of the feature as well as give feedback and iterate quickly.
New design for calendar management

Results: launch to many smiles

Google 2-Way Sync launched in WooCommerce Bookings in Feb. 2019, on time and to much customer delight.

Besides successfully launching the feature, the processes we implemented became a foundation for how the team worked together, and other product teams across the division began exploring them as well.

Bookings: time zone conversions

Challenge: shipping a feature in a short time frame

After finishing our proof-of-concept and scoping for a major feature (Google 2-way sync), we determined we needed several months to complete the feature. That meant we couldn’t ship it before the holiday season, and would need to leave it for early next year.

With this feature pushed to the following year, we had a short gap in our roadmap.

Solution: find something bite-sized

I maintained a backlog of ideas, drawn from customer suggestions, support interactions, and design reviews of the product.

I updated the backlog with additional data from our Customer Survey, and created a shortlist of features to consider. Working with the engineering lead, we narrowed the list to one high-impact, easy-to-ship feature: time zone conversions, meaning giving store owners the option to show available times in their customer’s time zone.

I defined the scope of the feature, and the developers were off to the races. On a weekly basis, I saw demos of the feature in progress and provided feedback.

Knowing we had a short turnaround, I also kicked off launch planning by drafting a marketing plan, including the value proposition and audience, and oversaw development of marketing materials.

Results:

Within five weeks, we went from identifying the gap in our roadmap to putting the feature in customers hands. The process helped the team get used to shipping features more quickly.

We saw positive engagement with all launch communications, including the first post on our extension developer blog.

WooCommerce Customer Survey

Challenge: Lacking data

While WooCommerce had access to basic first-party usage data showing which products were used by customers in which combination, we lacked firmographic or demographic data about purchasers. Without that kind of information, we were struggling to:

  • Recruit a representative set for qualitative user research
  • Understand the types of customers we were trying to serve, and create customer profiles
  • Shape a roadmap for lower-value products, where dedicated research wasn’t called for

Solution: Send a survey

Partnering with design researchers, I built a survey to capture key data from existing purchasers. That included data about their:

  • Persona, meaning whether they used WooCommerce to make website for others or to manage their own business (developers vs store owners)
  • Business, such as how long they’d been in business, what they sold, what industry they were in, what their revenues were and more
  • Skills, such as their familiarity with key technologies and how they spend their time
  • Spending, meaning specifically how much they’d spent in different categories in the previous year
  • Demographics, like age, gender, and location

Results: Rich data set for product decisions

We recruited 2,600 respondents, including more than 750 for each of our key personas (developers & store owners). Working with the data team, we conducted a cluster analysis to identify which traits were closely correlated and build customer profiles.

The type of data we now had access to included:

  • Customers who offer appointments, reservations and bookings were more likely to be in the Travel or Professional Services industries and offer non-traditional payment options, such as paying by invoice, setting up a deposit, or offering a recurring payment. Bookings, our flagship extension, allowed customers to offer these types of products with WooCommerce. This data helped us target qualitative research around Bookings, as well as shape both the roadmap for the product and marketing initiatives.
  • For most customers, the majority of their business was online, but older businesses were likely to have started offline and have some type of offline presence. This told us that POS integrations like Square would be valuable for this customer type.
  • Different types of developers had different spending habits – assemblers (less-technical businesses) spent more on themes, where agencies (more technical) spend almost nothing on themes. This suggested that themes was a potential product area that could appeal to the assembler audience, which we weren’t catering to.
Read more

I shared our findings on the WooCommerce blog

This data became the foundational knowledge that we built our roadmap and future research endeavors around. It also informed what types of questions were valuable to ask during account sign-up on-site and during registration in-product, which shaped our on-boarding in both of those contexts.

WooCommerce Marketplace Relaunch

Challenge: an unsustainable business model

WooCommerce runs the official marketplace for WooCommerce extensions – essentially an app store for additional features that are too niche to be part of the core product.

The terms of the Marketplace included:

  • A 50/50 revenue split with developers selling their products via the Marketplace
  • WooCommerce handled all support and marketing for all products sold
  • Developers were responsible for maintaining and updating extensions, but needed to go through WooCommerce to send updates out to customers

In early 2016, the leadership team at WooCommerce decided to close the Marketplace to new developers and products because this model became unsustainable – the team couldn’t keep up with marketing and supporting a catalog growing in complexity, and often a new product wasn’t worth the marketing and support burden.

Later that year, we started exploring what bringing new products to the Marketplace would look like. I was tasked with formulating a new model, defining product requirements and relaunching the Marketplace.

Developer experience on WooCommerce.com, prior to relaunch

Solution: redefining the terms, focusing on a quality product experience

Working with the business intelligence team, we conducted a two-week sprint to identify the key changes we needed to make:

  1. We were taking on too much responsibility: We needed to shift responsibilities like support, marketing and deployments to developers, who were better positioned to serve these functions than our team
  2. We didn’t provide developers enough tools: In order for developers to take more ownership over their products, they needed tools to deploy updates, edit product pages, view revenue data, receive support inquiries and more. To do these tasks well, they needed guidelines, which at the time were not public and thus inaccessible.
  3. Our processes were invisible: Developers would often pitch products to us via personal emails to their contacts, which was silo-ed and not transparent. We hadn’t established standards for evaluating those products, so there were inconsistencies in how they were judged. Finally, because it was hidden in email, we didn’t have data about our rejection rate, common issues or how long it took from proposal to launch.
  4. Our infrastructure was clunky: The infrastructure that powered our Marketplace on WooCommerce.com hadn’t been reviewed in some time and wasn’t built to scale. For example, data about the owner of a product, including their name and payout terms, was stored on the individual product. As a result, when a developer changed their name, it needed to be changed on each product, by our team.

Over the next nine months, I led an initiative to resolve these challenges:

  • Restructured the Developer Agreement terms: including updating revenue sharing terms to 60/40 and shifting marketing, support and deployment responsibilities to developers.
  • Created a roadmap to update the product experience on our Marketplace, for both developers and our own team:
    • New architecture built on Product Vendors (a WooCommerce-made extension for WooCommerce) created a ‘vendor’ taxonomy and solve many inconsistency and data problems.
    • Product submission flow took product pitches out of email and into a structured place, where we could ensure consistent submissions, get data, and create processes for evaluations.
    • Support routing meant support inquiries for developer products were routed, via email, to the developer’s own support tools, rather than to our support team.
    • New developer dashboard, which let developers manage marketing copy and submit products for review
    • Public documentation about how to write marketing copy, the terms of our marketplace and how to provide support
  • Ran a beta testing program with top developers to validate new features, and then rolled out the new program to all developers.

At this point in the roadmap, I spoke at WooConf about our progress and goals.

Once the process was working well for existing developers, within four months, we opened up the Marketplace to new developers by:

  • Creating a developer sign-up, where new developers could register
  • Adding new reporting features to give insight into revenue, subscriber and refund numbers
  • Launching a self-serve deployment flow, to let developers manage updates on their own
Submission flow
New revenue statistics
New usage statistics

Results:

For the initial relaunch, we retain 97% of developers through the transition and decreased support burden on our teams by 15%.

Once we opened the marketplace to new submissions, we saw a 13% increase in our product catalog within 12-months.

WooConf 2017

Challenge: uncertain value

WooCommerce is an online platform with an active community. Alongside community-led meetups, the team ran a semi-annual flagship conference.

While the conference felt like a meaningful experience, the leadership team questioned the value for the platform, and the impact for attendees.

Solution: data, data, data

I took the helm for WooConf 2017, with two main goals: improve attendee experience and increase value for WooCommerce.

Improving the attendee experience

Focus on what the data says we do well: Previous iterations of WooConf included a wide range of topics all around eCommerce, and aimed to serve both the developer and store owner audiences. From analytics around other content, I had a hypothesis that more niche, WooCommerce-specific content would have higher value for our audience, and that focusing on the developer audience (who was more invested in WooCommerce) would create a better experience.

Some other actions we took based on existing insights:

  • WooCommerce is community-based, so we used our existing community Slack instance to interact with attendees during the conference
  • WooCommerce is built on WordPress, so we specifically chose a location (Seattle) that had a robust WordPress community
  • Email and discounts were effective marketing channels for us previous, so we primarily utilized those channels to sell tickets

Ask attendees what they want: We didn’t have strong quantitative data from previous events around what attendees wanted. To fill this gap, we included qualitative interviews as part of our planning process. Our speaker coordinator spoke with ~10 target attendees to understand what they’d want from a conference like WooConf. The result was a list of topics and types of speakers we targeted.

From these interviews, we confirmed that speakers were a primary draw for attendees, so we focused on getting big-name, relevant speakers.

Design legend John Maeda on the main stage
Seattle-based SEO expert Rand Fishkin

Increase the value for the platform

Create opportunities to learn more about customers: Because being face-to-face with customers is a rare treat. To take advantage of this opportunity, we set up a customer research lab, where our design team conducted user interviews.

To improve our quantitative data about the event itself, we also used Slack to get attendees to give speaker feedback, and sent both a pre- and post-event survey, both in dedicated emails, with reminders.

Create memorable images, content that can be repackaged: We had two big headlines that we wanted to share: that WooCommerce is a large platform, and that we were opening the marketplace. We used WooConf to highlight those messages.

Todd Wilkens, Head of Woo, giving the opening keynote

We also wanted to highlight products sold by WooCommerce stores, again to show the breadth of WooCommerce. We gave customized Lego mini-figs to all our speakers and staff, made by a WooCommerce store.

Results:

WooConf 2017 yielded nearly 10x the amount of individual data points as previous years, proving clear value for the Woo team.

Attendees rated all aspects of the event highly, and were impressed with the big-name speakers:

Auto-Woo-newals

Challenge: low renewal rates

WooCommerce sells extensions which need to be renewed each year.

The renewal process is manual for customers. They essentially get a notice to renew, and need to go click to go to the site, then go through a checkout flow, re-enter their credit card details and so on.

The result was relatively low renewal rates.

Solution:

To make things easier for customers, and to improve renewal rates, I led a project to implement autorenewals. The key changes were:

  • Moving to a new payment system, which included storing credit card information and automatically charging renewals on the subscriptions expiration data
  • Designing new screens for showing the saved credit card information, and allowing customers to change it
  • Updating the checkout process, to inform customers about automatic renewals
  • Writing two sets of new email notifications – one encouraging customers to opt-in to autorenewals, and another informing customers about an upcoming renewal
  • Designing the logic of the autorenew system, including how to retry failing cards and opting in users who make a new purchase
  • Launching reporting for autorenewals, to understand how successful the project was

Results:

Within a year, shifting to automatic renewals double the renewal rate, and we received no negative feedback from customers about the change.

‘United for 90 Years’ Timeline – Responsive

'United for 90 Years' Timeline - Responsive

Project overview:

To recognize the 90th anniversary of United Way for Greater Austin (UWATX), UWATX wanted to create an online experience to draw in new audiences and delight existing ones.

I came up with the concept of a responsive timeline highlighting UWATX and Austin history, including filtered views targeted to niche audiences, oversaw design and development, researched and wrote 200+ highlights and promoted it extensively across all channels (social media, social advertising, e-mail).

Results:

During the initial 90-day campaign, the timeline drove an additional 10 percent of traffic to our website above our normal traffic. Of this traffic, 72 percent of this traffic came from new visitors versus site average of 67 percent. Users also average twice as much time on the site when visiting the timeline.

Read the full case study

10 Lists of 9 Series

Content marketing: 10 lists of 9

To take advantage of the trendy listicle format for UWATX’s 90th Anniversary, I developed, oversaw the research and writing and managed social promotions for a “10 Lists of 9” blog series published during the 90-day campaign. Among other results, the series drew 450+ visits from Twitter alone in two days.