Welcome to Resourceful, Lattice's guest column for leaders working on the cutting edge of People strategy. Whether you're looking for tactical tips or big-picture ideas, our authors' advice can make you a more effective HR leader. Subscribe and never miss a column.
Talent teams have a long history in operations and compliance-related work. It comes with the territory and is so fundamental to the smooth operation of a business that it can be difficult to make room for other things. At the same time, many People professionals are itching to work in environments where they can spend more of their time improving the long-term experience of their people.
To make this shift, you have to embrace one simple truth: Employee experience is the core product of great talent teams. Almost everything else those teams do should be viewed merely as the operational/logistical byproduct of that focus.
With this focus on value to the customer (ahem, employee), People leaders need to think like product managers running agile product teams. For many, this change of framing/skills will be the catalyst for a radical modernization of their organization.
To understand why, consider the following off-putting onboarding experience:
Sarah was excited to be joining AppBook as a software engineer working in their R&D division. There was just one week left before the big day and her welcome pack had just arrived. It included a t-shirt, water bottle, and notebook. The enclosed letter asked her to complete an equipment preferences form and send it back at least two weeks before her start date. She loved the water bottle and notebook but discovered that the t-shirt was a tight-fitting medium (she needed an XL). She wondered whether she was expected to wear it during onboarding.
As it was overdue, she immediately filled out the form but then realized that it didn’t specify who should receive it. She pinged her only point of contact, Leo (her recruiter), waited a day for him to get back from vacation and then another day while he asked the PeopleOps team. Now, five days before her start, she sent the form back via email (using her phone to scan it since she didn’t have a scanner/fax machine at home).
This kind of disjointed experience arises when holistic questions have either not been asked or don’t have coherent ownership. Questions like,
- What should a new hire do if they get the form after the deadline?
- What do we need to ask them and in what order?
- What decisions depend on their answers?
- Is it always clear what the company is asking them to do?
Product management tools like user stories, journey mapping, and service blueprinting attack experience gaps head-on by helping cross-functional teams dig into every stage of a process. In this case, for example, picturing what the new employee would actually do with the shirt once she received it would almost certainly have triggered the question, “Won’t we need to know her t-shirt size before we send out the welcome pack?”
IT processed the form the next day and contacted Elaine (her hiring manager and a leader in the core products team) to get details on her requirements. Elaine reckoned she’d probably need ‘build 3’ as she’d actually chosen to join the R&D team towards the end of her offer process. For safety, Elaine recommended that they contact Suresh (her actual manager in R&D). As they were short on time, IT decided to go with ‘build 3’ and to let Sarah/Suresh deal with any additional needs when she arrived.
Product-oriented teams place the entire customer experience at the center of their thinking. Most operationally-oriented teams, by contrast, are measured by the efficiency with which their clients can complete the tiny pieces of the journey for which they are responsible. When the little bits run efficiently but don’t plug together smoothly, the result can be confusion, inefficiency, and otherwise-avoidable damage to the reputation of the organization. Tools like product and mission chartering are an essential part of helping specialists understand that they should think of themselves as collectively contributing to one deliverable: an excellent experience.
The problems continued throughout Sarah’s first week. She just assumed she’d experience a set of hiccups particular to her situation. So did the six other new employees who’d (unbeknownst to each other) had had a raft of similar problems.
What tools and team norms might have helped prevent these issues and ensured a great onboarding experience for Sarah and her colleagues? Thinking like a product manager, we can identify five foundational steps that arise from a product-thinking mentality along with some tools that are often helpful.
1. Know your customer (in this case, new hires).
- Who are they? (Tool: Persona analysis)
- How will they think/react? (Tool: Empathy mapping)
2. Understand their problems.
- Is onboarding a coherent experience? (Tool: Journey mapping)
- What gaps exist in that experience? (Tool: Blueprinting)
3. Ideate and co-create.
- Recruit recently onboarded teammates as well as others involved in the process to build out a set of solutions (Tool: Ideation workshops)
- Have a larger cohort of colleagues talk about their views on potential solutions (Tool: Focus groups)
- Ensure that the complete set of teammates working on the various parts of the experience work together on this single "product" (Tool: Cross-functional teams)
- What is the smallest change you can make quickly? (Tool: Minimum viable product analysis)
- Resist the urge to change lots of things at once or to deliver change in a way that takes a long time (Tools: Sprints, demos, WIP limits)
- Can you limit the blast radius and take risks? (Tools: Pilot programs)
- What are your key measures of success? (Tools: KPIs, CSat, NPS)
- How are you getting a clean signal? (Tools: A/B testing, sampling)
- What are your customers saying? (Tools: Surveys, interviews)
- Are the benefits of your choices durable? (Tools: Longitudinal studies)
If this is all new to you, don’t try to boil the ocean. Start by aligning your team around what it means to treat employee experience as a product and then introduce the first step. Product management is a marathon, not a sprint. You can also reach out to me for support and advice.