In my previous product role, our team interviewed in a Product Trio and delivered using Shape Up. These Ways of Working enabled our small team to consistently over-deliver. Below are the key moments I played in our first v1 product, Automated Membership. From framing the problem, to shaping the UX, and seeing it through launch with a technical understanding, I guided the project to done.

Framing
Before I joined, the Director and Product Leader decided that my team will focus on the Employee Onboarding process for the 10K-person company. This direction was convyed to me from our organization's Product Leader.

To find insight in this ambiguous problem, I began interviewing new-hires about their recent onboarding experience. And noticed a pattern that many of them search for and wait to be added to groups. This gives them access to tools and news. So I started interviewing the owners of these groups. Which were often People Ops, fellow subject matter experts (SME's) for onboarding. Each week they updated their lists with new hires. They filtered for people who were part of their Organization and had specific role types, like Engineering or Product. Then manually added them to the groups.

Membership for other groups were based upon whether the individuals are a People Manager. And often front-line engineering managers wanted everyone that reports to them to be apart of their squad's group. Each opportunity was discovered during an interview and shared with the team using an Interview Snapshot, like the one below.

I also looked at the logs and saw thousands of people manually added to groups each year. I had enough to frame the problem.

These moments led to a framed problem, ready for a solution to be shaped.

Shaping
We could automate group membership by letting group owners define filters and automated actions for each of their groups. I wanted to design the interaction flow to configure rules, and called a working session with our lead engineer. Walking through the use-cases, we created a breadboard.

We came across a feasibility issue. To find the right people, some group owners used a free-form query, provided by Workday, to extract meaningful attributes. For example, whether or not someone is a people manager. This deeply nested query checked if a person has Direct Reports and if at least one of those Direct Reports is not a Consultant. To replicate this functionality, it would take months of work. And we only had six-weeks to build.

I noticed that most of the filters that group owners used were simple and required at most two levels of And/Or nesting, e.g., find all Engineers that belong to the Security organization. The lead engineer said that one-to-two layers of nesting is straight forward to implement. So we called complex filtering out-of-scope.

To filter for whether someone is a manager, I pushed further with two ideas: asking HR for this data and deriving it ourselves. The engineer said they need a seperate code spike to determine if we can augment the dataset. And it usually takes HR a few weeks to send us new data. So we agreed to check the feasibility, submit the data-request to HR, and call is_manager nice-to-have.

Later, I sketched a key screen of the UI. And I called another shaping session with the Engineer and Designer.

From the sketch we hit another feasibility problem. Autofilling values for the filters could also take months of work. As a workaround I suggested that we reference a spreadsheet with the valid values. The Designer agreed that is usable enough for our first version. The shape was a go.
‍

Building
To initiate the 6-week build, I wrote the frame and shape in a product pitch.

‍
In our kick-off meeting, I shared the pitch with the team. The other engineers digested the document and asked clarifying questions. They understood what to build and created a plan of attack.

While the team built, I drafted the marketing content for each channel. Which included the Slack group for People Ops.

During the build, the engineers noticed useful functionality that we had not discussed. A "bulk add" feature that adds members all-at-once instead of each week. I deemed it nice-to-have and a likely feature of v1.1.

HR also sent us the is_manager attribute in time for v1.0.  

About a week before building ended, I QA'd our product and found many issues. I collected the team for a bug bash, where we documented issues and prioritized fixes. In a retrospective we agreed that next time the engineers will QA first.

Launch & Learn
To release our product, we posted marketing across channels, monitored reactions, and I responded to inquiries. People Ops invited me to demo the product in their monthly meeting. Afterwards they asked questions, gave insights for additional features, and configured their own rules.

We also captured product usage and interviewed users to learn their needs. To have confidence in the automation, customers wanted to see when and who added someone to a group. Was it the automation or a person? To know if the filter is set correctly, users needed a preview of the people. This has the bonus effect of showing who is missing from the group. The "bulk add" functionality addressed this use-case, as well as populating new groups from scratch. And to our delight, the simpler nesting was powerful enough to address every query.

Our Product Leader asked me to demo the product in our company-wide conference. I also presented our Ways of Working to our 50-person organization. With support from leadership, we used the learnings to iterate over two more build cycles. While I tracked impact. Over 100 groups were automated, saving approximately 10 minutes per each onboard.
‍

Idea through Done
From a direction, I guided and developed an idea through launch. By collaborating with Engineering and Design in the shaping phase, we de-risked the project. The product pitch then empowered the team to build asynchronously. No need for daily standups or managing a backlog. Instead I used this time to create marketing and frame other problems. The process is sustainable and consistently delivers.