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.

Surprising Findings about the People Behind WooCommerce Stores

In early 2018, I became the first-ever product manager for the suite of 100+ WooCommerce extensions that are made and maintained by Automattic (the company that owns WooCommerce).

To shape a future for this catalog of extensions, I started by digging into the data. Collaborating with the designers that joined our fledgling extensions team, we spoke with the support team, analyzed purchase behavior, and looked through the Ideas Board, where customers request features.

Even with this research, we didn’t feel we had a clear, data-driven, wide-angle view on the landscape we were trying to serve, so I ran WooCommerce’s first-ever Customer Survey. Building on that data source, I worked with the data team to create the organization’s first customer profiles using a cluster analysis to find related traits.

Here’s the full post about what we found, over on the WooCommerce blog.

The Past, Present, and Future of WooCommerce

This year has been an exciting time for WooCommerce: we opened the Marketplace to new submissions, we launched our first Gutenberg blocks and we’ve started engaging in new ways with the WooCommerce community.

We’ve also had a lot going on behind the scenes, including our first-ever Customer Survey, which has given us new insights on who we’re serving, and a new initiative to reimagine the design of WooCommerce from top-to-bottom.

I joined Todd Wilkens, Head of WooCommerce, and Kelly Hoffman, Director of WooCommerce Design, to share more about the past, present and future of our platform for WooSesh, the online conference focused entirely on WooCommerce.

You can see the full video here, but you need a membership.

Here’s me speaking with Patrick Rauland leading up to the event:

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.

On being a digital nomad

I’ve been location-independent for more than four years.

When I left my desk job, I was looking for a role that supported my development as a full person. I deeply value getting new perspectives by putting myself in someone else’s shoes, so I wanted a role that let me be in different locations.

I found that at Automattic, one of the world’s largest distributed companies.

For just over a year, I’ve been taking advantage of this to the fullest by splitting my time between Austin and Berlin. This year, I’ve been to eight countries and spent more than a third of my time away from “home” (Austin).

Beyond getting to be in different places myself, working in a distributed company means my coworkers are distributed as well. On a daily basis, I’m talking to folks in New Zealand, Poland, South Africa and San Francisco. I get the pleasure of hearing diverse perspectives in a way that I wouldn’t have access to otherwise.

Just a few of the tidbits I’ve learned:

  1. It feels drastically different to start your day with a meeting vs to end your day with it: Because of the time zone difference, my schedule in Berlin is quite different from Austin. My teams are global, so meetings are scheduled to maximize overlap between Europe/Africa and the US. In Austin, that means morning meetings. In Berlin, that means late night meetings. I am almost an entirely different person, because the time-of-day difference means a meaningfully different brain space. That gives me empathy for my colleagues who are in a different mental state because of their time zone.
  2. Different countries have different holidays: I knew this on an intellectual level, but until hitting the streets for May Day in Berlin, it didn’t fully sync in. Especially for times where round-the-clock coverage matters (customers support, marketing tech during sales), it’s important to check-in about these holidays, or you can accidentally put someone in a tough position of choosing between celebrating their culture and doing their job. (Thanks to @ValDeOro for pointing this out)
  3. *Everything* is backwards in the Southern Hemisphere: Summer is winter, school years run from January to December and so much more. Working with a team that included folks in South Africa and Australia helped me appreciate how much of our communications and planning ignores half the globe – ‘back to school sales’ in September don’t make sense for South Africans, for example. (Thanks to @JobTex for this)

Tortuga Backpacks is another fully-distributed company, and I recently spoke with Jennifer Sutherland-Miller from their team about my experience as a digital nomad. Read all about it.

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.

Insights from the WooCommerce Marketplace: Successful Extensions are Built on Understanding Customers

In 2017, the WooCommerce Marketplace had been closed for more than a year. In that time, our team wasn’t accepting any new products for sale on the platform’s official marketplace, yet we were gathering more and more data about what customers wanted and seeing where developers had a chance to serve those needs.

As we started to think about re-opening the Marketplace, I analyzed our first-party data to define what we wanted to see launch. I presented that analysis at WooConf 2017, and via the WooCommerce blog.