What a Year of Prototypes Taught Me About Fixing a Process

As we are going out and presenting the completed version of KITA Planning to a lot of our friends, a question that is almost always asked is "why did you think there was a need for KITA?"

It's a natural question. A lot of people view the strategic planning and goal setting process as something that's pretty arcane. For a lot of years, companies have just been putting this kind of thing on a form or in Excel and never thought much more about it.

Similarly, the precursor to KITA was a spreadsheet. One of my clients asked me to wire up a performance management tool that would cost them nothing. While it wasn't the perfect situation, I viewed it as a challenge and created it using a spreadsheet and a lot of Google Sheets automation.

Interestingly, it worked. Nobody liked it. But they had to concede it actually did the job.

Looking back, that first version taught me more than the polished ones that came after. So here's the honest story of how we got from there to a product, and what I'd tell anyone trying to fix a process that everyone does and nobody enjoys.

The Problem We Walked Into

We were helping a Malaysian non-profit with its annual goal-setting. The setup will sound familiar. Last year's goals sat in one spreadsheet. The five-year strategic plan sat in a PDF. Every manager got a blank form and a deadline.

The managers weren't the problem. They knew their teams and their jobs. Honestly, while they appreciated the fact that we could tell them with clear data how each person was doing, the process of getting everything set up was less than ideal. In many cases, the goals we received were a near carbon copy of last year and I had to do a lot of cross-checking with the budget, the strategic plan and even between the teams to see how everything aligned. You could kind of understand why enterprises paid consultants very handsomely for this kind of work.

The experience also had a bit of a pain point built in. Because HR has been so administrative for so long, we often see people being assigned tasks and then months later turning around and saying those tasks or metrics weren't clear or ever explained to them. As a result, in the implementation stage, a lot of things were missed.

The other thing I would also often see is that we would go into February or even March before we would communicate the actual goals to each member of the team. By the time everyone actually filled out the spreadsheet and the HR team and head of organization got to review and approve everything, the process just stretched and stretched.

I really felt something was broken. So I figured, maybe there's a technology tool that could help with this.

Attempt One: Automate the Form

My first instinct was automation. We connected a few no-code workflow tools. A manager filled in a form, a workflow looked up their team's data, and a spreadsheet came out the other end.

After a lot of work, I had a crude project ready to run. But when we watched managers use it, it was clear that all we'd built was a longer form. They still had to do all the thinking, with none of the context. We'd made the admin faster without making the decisions any better. Some managers asked "why can't we just use the Excel?" Sadly, this is the nature of most changes. Even though there are better ways to do things, even a lot of very smart people don't really like change.

It's why I always quote the Billy Joel lyrics "The good old days weren't always good and tomorrow ain't as bad as it seems" when I talk about change.

Attempt Two: Make It a Conversation

What managers needed was closer to a conversation with someone who'd done the reading. Someone who already knew last year's numbers and the strategic plan, and asked one sensible question at a time. It occurred to me that we had to up our game and think about the problem differently.

So we built a goal coach on a general AI model and loaded it with the client's documents. A manager could say who they were, see their team's previous goals, and work through what to keep, change or add.

This was much closer. Managers could see their old goals instantly, and the coach could point to parts of the strategic plan they'd never have connected to their own team.

It also showed us how much has to be right before a manager trusts a planning tool. The AI sometimes filled gaps with things that sounded plausible but weren't true. And a general chatbot couldn't reliably enforce the rules a plan needs, like every goal having an owner and linking to a priority.

But there was still something missing. We live in an era where team members look for feedback and a voice of their own. We realized that we needed mechanisms to allow for a wider diversity of voices. I can tell you from my experience in retail, even while I was running 50 stores across 11 provinces in Indonesia, I would always come back from a visit to other provinces amazed that my team had taught me something I didn't know. It got us thinking, when we design goals and plans, how much did executives really know about what was happening in the real day-to-day of the business? And how many of their plans were failing because that kind of floor-level institutional knowledge wasn't being transferred up? That knowledge "gap" seemed like a real problem.

There was one other element that was important. Years of HR work had taught me that while good process was important, good communication was even more critical. If you have the best product in the world, if nobody understands what it's saying and how it helps, they'll never accept it. This really begged for a proper, super-clear process for explaining the output of the strategic planning process to each team member. Again, this seemed like something we needed to build into the technology.

Attempt Three: Build the Real Thing

That's when we stopped stretching general tools and started building KITA properly, creating a balance between trusting AI and putting in proper guardrails. However, we can say the first two attempts set the stage.

In short, we realized we needed to let the AI do what it's good at: reading documents, drafting goals and asking good questions. At the same time, we needed the solution to enforce the rules: owners come from real people data, every goal links to the one above it, and every suggestion shows where it came from.

A mentor warned me early that getting the goal drafting right would be the hardest part of the whole project. He was right. But it's the reason we've invested so much in the goal engine (and are still improving it) to cut the time to "the right answer" and allow managers to spend their days doing the work they rightly feel is most important.

What I'd Tell Anyone Fixing a Messy Process

Watch people do it first. Before you design anything, sit with the people who do the process today. The pain is rarely where the form is.

Don't automate the form. Ask why it exists. Our form existed to help managers make good decisions about goals. Automating it made the paperwork faster without helping the decisions.

Build the smallest thing a real user can try this week. A rough prototype in front of a real manager taught us more than weeks of planning.

Test with real data, early. Sample data hides problems. Ours only showed up when real managers used real records.

Expect the first version to be wrong. Ours were. So was the second version, the third and so on. Each one told us what the next one needed to be.

Learn "whiteboard thinking". I often use this term. It means that instead of merely automating a process that exists and working off that model, you should wipe the whole board clean and think of it as a fresh slate to be built properly with automation around it.

Infer whatever you can. One of the things we leaned on at KITA was the idea that whatever information we could collect "by proxy" based on what a user already answered was where we could deliver the real time savings and "surprise and delight" to the user.

Communicate! The one thing everyone forgets about redesigning a process is that nothing really matters if the final output isn't clear and easy to communicate and understand at every level of the organization. Write the process for the output, the destination, not for the process (i.e., the journey).

What's a process at your company that everyone does and nobody likes?