On Prototyping, Iterating, and Anchoring

7/23/2023 - Kyle McVeigh

Go back to all articles

A great part of my job is meeting with the business and hearing about their problems and ideating alongside them about how we can use technology to reinvent processes to solve emerging problems. My background in finance allows me to sit with the decision makers and make solutions without any intermediary. Each new problem is unique and requires all of my cognitive abilities across finance and computer science.

Due to secrecy concerns I won’t give any specifics, but I’ll describe the typical process generically. Typically the business has a new concern: the market is always changing, business risks are always evolving, and inevitably there will be a novel problem on the horizon and there is no legacy system or process in place. I’ll be looped in early and provided the details, which I try to category as the inputs and the concerns. At that point i’m unleashed to preset a solution that solves the problem and doesn’t interrupt the business.

I guarantee my solution won’t be the final solution. While I do understand the business, I am not the business. I’ve made my career at companies where the technology team plays second fiddle to the business and that is a deliberate decision i’ve made. I want to work along people who are smarter than me who are working on the toughest problems. But it’s critical that the first solution I present be my best work. I need consider edge cases, longevity, and friction in my initial solution because it will anchor the iterative solutions around that first prototype.

I recently was presented with a business problem that had urgent needs. After hearing the problem, I realized we can get somewhat close with a no-code solution using monday.com and gave that back to the business same day. It was a huge improvement on their current process, but made iteration difficult. The business was hesitant to leave the no-code solution and I lacked absolute control on this no-code product. While it was a quick win, it was a long term mistake.

Anchoring is now a major thought when I build a new product. I have creative control when I’m first tasked with solving a new business decision. It’s critical I use that freedom to present a solution that has long-term viability and flexible to be iterated on. Additionally, I need to test my understanding of the data and how it’s stored relationally and any hard assumptions I made along the way. I find these are the hardest things to iterate on so it’s critical I solve for them early.

Working alongside the business closely is a privilege and I take it as so. It is a very careful balance of when I loop them into my first solution as that first solution will be sticky in their mind. Iteration is godly and I need the business involved as quickly as possible to get to a fully fleshed product, but it’s my responsibility to present my best effort as the first draft. Striking this balance is a constant challenging that I’m still learning.