The pursuit of customer value

Stefanie Häuser
Inside Personio
Published in
6 min readFeb 22, 2019

“Fail, fail again, fail better.” — Samuel Beckett

Last quarter we failed.

We wanted to delight recruiters by re-defining the user experience of a core job our product supports — interview scheduling. A task lots of recruiters complete many times a day which required back and forths between Personio and multiple other tools.

Improving a high pain, high frequency job seemed like a straight forward and sure-fire way to make our customers happy. It was the right problem to solve. So what could possibly go wrong?

If you work in tech or a similar industry, you already know the answer: many many things. And that is what I will talk about in this blog post: what we struggled with and the things that eventually went wrong. How we failed to deliver on our originally designed solution but ultimately still created value for our customer.

The problem we set out to solve

Personio’s recruiting software already offered a way for recruiters to schedule interviews, however, the experience was the opposite of seamless. We saw recruiters jump back and forth between Google calendar and Personio, creating events in both places. Instead of helping them, we were actually doubling their workload.

User research helped us understand the main pains:

  • Not being able to see employees’ calendar events and availability
  • Not being able to book rooms directly through Personio

Additionally, recruiters were also missing context like an overview of bank holidays and employee absences in order to choose the best time slot for an interview.

The solution we envisioned

Based on these insights the discovery team explored possible solutions. It became clear to us that the engine powering the new experience would be a third-party calendar API allowing us to integrate with both G-Suite and Microsoft.

We know that due to legal reasons, not all customers might opt into the new experience. Therefore, one of our big goals was to improve the usability of interview scheduling for all customers, calendar integration active or not. Over the following days and weeks, our vision grew and was refined through prototype user tests and feedback.

In the end, we landed on a completely new way to create interviews with a wizard as well as a redesigned overview page. ​​The list of pain points we were going to address was long. We felt like this new experience was going to be truly seamless and delightful.

The kick off we struggled with

During the discovery and design process we had regular discussions about feasibility and effort. However, we hit a wall of uncertainty when it was time to set Q4 OKRs. We identified the following problems:

  • Tech plan: No one had actually really worked with the chosen API before. Estimating effort was almost impossible because we lacked a detailed plan for the architecture and its validation.
  • Scope: Due to the lack of confidence, it was extremely difficult to commit to a specific scope for the project. We knew that delivering on the whole design vision was a stretch but we also really wanted to try.
  • Iterations: This was the trickiest part of the project. ​​Our top prioritized customer pain points required having the API integration work — exactly where we had the most uncertainty and where we predicted the most work (4–6 weeks) had to be done.

Based on our fear of not releasing anything for half the quarter, we initially came up with an iterations plan focussed on delivering customer facing changes early on. Half the team would start with improvements for the non-API version while the other half would start preparing the connection to the calendar API.

​​During the OKR planning for Q4, we decided to throw the initial release plan out of the window! As a team we decided to work on the highest priority pain points and to validate our riskiest assumptions quickly. It was our best option to fail early if we had to fail.

In order to make this happen, we had to adapt all our beautiful designs again to a way more basic version. We decided to focus our frontend effort on implementing and perfecting a calendar view inside Personio and our backend effort on validating the calendar API. From this version, we would then iterate and move towards our original vision.

The challenges we faced

Q4 ended up being a pretty intense quarter for us. We went through a forming-storming-norming cycle after a team member rotation. We dealt with extensive holiday periods. We spent almost a month finishing up our Q3 commitments, and, last but not least, dealing with high priority bugs. By the time we were able to start with our Q4 OKR focus, November was in full swing.

The last few weeks feel like a crazy roller coaster for all of us. We familiarized ourselves with the API and got started. Here some of the challenges we overcame along the way:

  • After making great progress initially, our engineering manager came back from vacation and immediately spotted some issues with the chosen approach. We had to pivot and change the architecture slightly.
  • In order to move quickly in the frontend, we chose an existing React component to work with. However, it turned out we had to upgrade our React framework in order to get the latest fixes for this component. With the help of all teams and some really great engineers, we got this done surprisingly quickly.
  • In the first half of December we were then able to test in production with a demo account…and immediately found some unforeseen issues with the API not behaving exactly the way we had anticipated. (As an example, we had to deal with secondary calendars)

At the end of the quarter, we hit a point when finally all the important things were working — we were able to display the interview participants’ calendar events and availabilities in Personio and to book calendar events including rooms via the calendar API. As a result, some of the other medium to high priority issues we wanted to tackle were rather straight forward at this point. We continued to work on the interview scheduling experience for one more sprint in January and eventually solved 5 out of the 6 customer problems we had committed to tackle.

The end result and what we learnt

Overcoming the challenges during this project has taught me how important it is to test critical assumptions early. If we had proceeded with the initial release plan, we wouldn’t have found out about many issues until very late into the project and would have wasted time building things unrelated to the core experience first.

At the time, I was quite apprehensive towards starting with the validation of the calendar API, out of the fear that we wouldn’t be able to test anything with real users for weeks on end. Retrospectively, this was the best choice we could have made.

There are two ways to look at the result of this initiative to improve the user experience of interview scheduling in Personio:

On the one hand, we only implemented a small part of our original design vision. The interview creation flow still isn’t a nice wizard, there are neither draft interviews, nor distinction between upcoming vs past. The interview overview tab is still a bit of a mess.

But on the other hand, we now provide a one-stop solution for scheduling interviews. Recruiters can open a beautiful calendar interface that shows them all the context they need to find a time. They can see their employees’ absences, bank holidays, employee and room calendar events as well as resulting available slots. They can book their chosen time with a room directly through Personio.

We set out to improve customer happiness with interview scheduling. In the end, we achieved an amazing 25% increase (measured by an in-app survey). A result we’re quite proud of!

Don’t get me wrong, my message isn’t that design is not important or that you shouldn’t have a vision of what a great user experience would look like for your product. On the contrary, this should be the basis for everything you do. But what I learnt from this project is the following:

It always pays off to tackle the big bets first — start with the core problem and the rest will follow.

From now on, we will always slice our increments in a way that focusses on customer value and will start with the highest impact piece that can be delivered — even if it it requires an up front investment. If it’s not going to work, let’s find out sooner rather than later.

--

--