product management
enterprise FINANCIAL software product

TABLE OF CONTENTS

case study

OVERVIEW

brief

process

DELIVERABLES

videos

OVERVIEW

Client

-  KinderCare Education
-  Children's Creative Learning Centers
-  Champions
-  The Partners Group

Location

-  Portland, OR

INDUSTRY

-  Child-care education and services
-  Financial / accounting
-  Tuition subsidy

COMPANY PROFILE

-  $1.6B company
-  World's largest early childhood education company

TECHNOLOGIES

-  Enterprise software
-  ERP software (enterprise resource planning) 
-  Financial and accounting software

Product(s)

-  Tuition subsidy financial software  

Project / feature / deliverable

-  Tuition Subsidy v1.0 (MVP)

duration / date

-  15 month release / 2015-2016

NOTE: Don't feel like reading? Watch the video at the end of this page.
 

BACKGROUND

This case study highlights my role as product manager for the Tuition Subsidy v1.0 MVP, an enterprise financial software product designed to work as a module of a proprietary ERP system.

KinderCare Education (formerly Knowledge Universe) is the world's largest early childhood education company with approximately $1.6B in annual revenues. It was founded in 1996 and became the dominant force in the North American child-care education services market, eventually acquiring a number of other companies and business lines.

The company has more than 2,000 centers and 31,000 employees in the United States, split among at least three brands and five business lines: KinderCare Learning Centers, Children's Creative Learning Centers, Champions, Grove Schools, and Knowledge Beginnings, among others. Many acquisitions predate the existence of the parent company, Knowledge Universe, by many decades.

Furthermore, ownership of the parent company has changed hands numerous times. In 2015, shortly after I began this project, the original parent company, Knowledge Universe, was purchased by The Partners Group, a global private markets management firm based in Switzerland. As a part of the purchase, Knowledge Universe's name changed to KinderCare Education, to take advantage of the size and brand recognition of the flagship business line, KinderCare Learning Centers. 

As a consequence of this complex history, there was a laundry list of monolithic technology issues, all of which profoundly impacted the work described in my KinderCare Education case studies:

1. The lack of continuity with corporate ownership and many acquisitions meant there had consequently been no progressive or consistent development of IT infrastructure for years or decades.
    
2. IT infrastructure was not centralized. It existed as an amalgamation of inherited, legacy technologies from the original enterprise, as well as that of acquisitions and disparate business lines.
    
3. Some acquired companies were almost 50 years old. Most key software systems were at least 20 years old. The company's most important system, an ERP application, was command-line based, and nearly impossible to enhance or maintain. 
    
4. As an enterprise with core expertise in child-care education, the company did not have the talent necessary to successfully execute IT projects. Instead of building internal teams with a long-term vision of knowledge retention and iterative development, year after year the company turned to different external vendors, agencies, and consultants. As a result, projects that should have been critical, internal initiatives were usually managed piecemeal by various short-term partners. 

The company resolved to address these problems in a multi-year enterprise IT program designed to modernize and unify IT infrastructure. But the nearly unassailable technology landscape that had evolved made for daunting obstacles. Leadership turnover had been extremely high, both within the IT department and the program itself, even at the highest executive levels. The program had actually been started and stalled several times. These factors set the major stage for all work within the program.

Tuition subsidy is reimbursement of private-pay child-care tuition, a financial benefit often offered to families and students by government agencies, corporations, and other similar institutions. Approximately 40% of all KinderCare Education students receive this benefit, and at least 33% of the company's $1.6B in revenues come directly from tuition subsidy, making it one of the company's top priorities. The Tuition Subsidy Group that manages this work comprises nearly 200 employees, both at the company's National Support Center (headquarters) in Portland, Oregon, as well as at approximately 2,000 field sites (child daycare centers) throughout the United States. 

problem

The project was full of overwhelming obstacles from the outset: the history of previous failures with the same work, the enormous scope of the software and its functionality, the complexity and critical nature of the financial calculations, the interdependence with legacy systems, and the need to satisfy the requirements of multiple business lines in one new software product.

The company had hired me as a product manager without fully understanding the different roles required for the product team, especially the distinction between management and design.

The company's two legacy systems that managed tuition subsidy were both on the verge of catastrophic failure. One system was command-line based. Employees were more often managing their work in Excel sheets than the legacy applications.

The mission-critical importance of the legacy applications, and their imminent failure, had the attention of executives and the board. Delivery dates were being established with no regard for scoping and resources. The pressure to deliver a working product was high.

solution

While working as primarily as product manager, I concurrently assumed product design responsibilities. The time commitment was excessive. But given the lack of budget or understanding for product roles, it was the reality of the project.

I tackled the work holistically, allowing the initial discovery process, over the course of the first 4 to 8 weeks of the project, to inform the framework of product vision, roadmaps, and backlogs.

For the sake of practicality, I tried to limit my design work to high-level vision and wireframes. I developed a Lean Agile process, establishing a set of UX style guidelines based on Google Material Design, produced sketchy wireframes using Balsamiq, and led cross-functional UX design reviews. I appointed a front-end developer, who was a talented UX designer in his own right, to realize implementation of UI development.

I waited until on the design side we had a solid information architecture established as a scaffolding for all our work. Then as product manager, I used this as the cornerstone for a multi-release product vision and backlog, which served as the basis for moving work to the rest of the team, especially engineering. I quickly put development work into play with daily Scrums, sprint planning, retrospectives, and other standard Agile Scrum ceremonies.  

Challenges

Because the company's core expertise was in child care, and not software, no one at the company understood the essential nature or value of a product manager. In fact, the role had not been scoped into original plans, and likely contributed to prior failures. Some of the misunderstandings and doubt persisted even after I assumed the role. It was often difficult to convince stakeholders to accept scoping estimates or timelines, because they had never approached development work using Agile methodologies Prior strategies had been limited to inconsistent bug tracking, to-do lists, and Excel spreadsheets. 

For similar reasons, expectations about success and timelines were varied and unrealistic. Without a product manager to properly scope work or manage release schedules, these details remained murky. In prior attempts, the company had intransigently held to randomly selected release dates that had trickled down from the executive level. That approach might have been at least served as a stake in the ground. However, when the timeline slipped or scope creeped, the release dates never changed, which created a continually shrinking runway for release of the software product. 

Personally, the commitment to manage and design the system at the same time was probably the most difficult aspect of the work. Each role was demanding in its own right, and I was trying to cram both into a single work week. For 16 months straight, usually 6 or 7 days a week, I never worked less than 60 hours. More often I worked 70 to 90 hours weekly. 

Outcome 

As the product manager, I created a vision of four releases over two years to reach an ideal product state for the Tuition Subsidy financial group. This vision included a rudimentary backlog, at an epic level, for all releases.

I also led product development and the engineering team to deliver the MVP product. The features in this v1.0 release offered parity with existing systems, allowing the company to begin migrating off off their problematic legacy systems.  

As a part of a business continuity strategy, I helped the company transition to an internal development team made up up KinderCare resources. For the duration of the  project, I had worked closely with a senior manager from the financial group who was assigned as a SME (subject matter expert). I additionally trained her to take over the role of acting Product Owner upon my departure. In effect, an Agile transformation was a hidden component of the project, and learning Scrum enabled the company to re-assume independence with the product upon completion of the MVP. The remaining release vision, artifacts, and documentation served as a blueprint for the company to continue with a coherent plan.

A case study about product management cannot help but be somewhat abstract, since much of the work is interpersonal and not documented in artifacts. So I encourage you to view the galleries and video demos below on this page. They provide screenshots, images, and examples of my work. My related case study about product design also provides additional insight into my product management and other work at KinderCare Education. 

design-management conundrum 

How do you manage a product that doesn't exist? If you design a product without a manager, who sees that it gets built? Recognizing that the missing product-design role was a huge problem might sound obvious to anyone who has worked in software-development environments, but was an essential first step in remediating this issue and educating stakeholders.

demystifying product management

It then fell upon me to educate stakeholders about the role of a product manager and build consensus. For people who had spent their careers in childhood education, it was difficult to understand how one role could be so pivotal. 

hybrid role

I assumed product management and design roles, knowing this was the only way to be successful under project circumstances. As a designer, my work remained blocked without release plans, timelines, backlog management, grooming, and a host of other work. I was partnering with myself in two roles.

design, manage, design, design, manage, design, manage

With two intertwined roles, you cannot just put the work in silos, and create a daily or weekly schedule to segment activities. It was always overwhelming to juggle management and design. I almost always worked 70+ hours a week. 

Agile ceremony and iteration

Structure and order evolved over months with this approach. A backlog took shape in JIRA. I decomposed the product and mapped its constituent parts into epics and user stories. The Confluence wiki served as the central repository for product management and design. Everything in JIRA and Confluece was linked, offering full traceability. Regular Agile ceremonies such as daily Scrums, Sprint planning, Retrospectives, and Demos bolstered project structure. Soon we were turning out features in sprints, and moving towards our first release.