Overview

Every few months, I like to develop and release a very small feature in the product. And when I say feature, it can be as little as a const change or a typo fix. I do it because I feel I need to stay close to the weeds to understand why development is such a complicated and often long process. Usually, something we think is small, and the developers say will take a couple of hours, ends up taking a day or two. I want to embrace the process myself to really understand it.

This is my detailed walkthrough of a “tiny” feature I recently developed and released.

Ideation

As part of my work at Port, my team developed and maintains the Port MCP server. One aspect of an MCP server that is often overlooked is the MCP prompts. A prompt helps users discover and work with your MCP server and its tools in a more structured way.

Recently, the team added static prompts, which are prompts that all users get regardless of their configuration. I thought we could a great use of them. One pain point we had was that customers wanted to use the MCP server, but didn’t really know how. The feature idea was to add a prompt that helps them discover, for their specific setup and organization, what Port AI and the Port MCP server could help them with.

I had already built a prompt that worked pretty well through Claude, and when the team released support for static prompts in the MCP server, I felt it was the right time to contribute my new prompt.

Setting up the IDE

The first step was setting up my IDE. I had to find the relevant repository, clone it to my desktop, and figure out what is the right service (we have a monorepo setup). I opened Cursor and chatted a bit with the Opus 4.5 model to understand the process of adding a custom prompt and asked it to generate some basic guidelines.

Then, I tried to check out a new branch, and it immediately failed because my branch name didn’t match the standards. With Cursor’s help, I found what was missing. I also had to open a task that this branch would correlate with. I went to our task management tool, which in our case is Port, opened a new task, and then checked out the branch again. This time it worked, and I had a branch ready to start working on.

Coding

Since I had already done some pre-work with Opus, I pasted my prompt and let the Composer 1 model from Cursor generate the changes. The changes made sense, and I asked several follow-up questions about why it chose one thing and not another, just to make sure I understood the implementation and that it didn’t hallucinate anything.

I then used Sonet 4.5 to double-check the code, see if it could improve anything, and confirm that the implementation was consistent with my contribution. At this point, I also noticed that tests weren’t written for the new prompt, even though we had tests for the existing ones. I asked it to create tests as well.

Unit tests

When I looked at the tests, I noticed something strange. Prompts can have dynamic arguments, which justifies extensive tests. Mine was a static prompt, so it didn’t make sense to have eight different unit tests. I identified what I thought was crucial to test and asked again to simplify the tests.

At this point, I went back to Opus 4.5, since I needed more critical thinking and wanted to make sure it didn’t just satisfy me without checking the logic.

E2E tests

This was probably the hardest part. If you ask developers how they test, you’ll probably get different answers from each one. Some already have their local setup and want to test everything to make sure it behaves exactly how they expect. Others trust the code and assume that if they change something static or hard-coded, it will just work. Some run commands and check through the CLI that things work technically.

My personal preference is to see the actual production experience that users will see, just locally. That was a major challenge. I had to ramp up on how to spin up the local environment. I sat with one engineer for an hour and a half, another engineer for 30 minutes, and in between ran something like 20 or 30 different commands until I got something to work.

Then I failed because of permissions. It turns out I needed specific AWS roles. I won’t expand too much, but it took more than a day to collaborate with the team, get the permissions, and refresh my AWS profile. Even then, the specific services I needed still didn’t work. At some point, I gave up and relied on a local environment that one of my engineers had. He checked out my branch, we tested it together, and once we saw it worked, I finally had the confidence to proceed.

Pull request

This was the point where I moved from local development to collaboration. I opened the pull request and worked through the template and requirements, and then tried to find someone who could review my code.

Before that, we already had an AI coding assistant set up, Codex from OpenAI, which reviewed my PR and gave one comment that made sense. I consulted again with Opus 4.5, it confirmed the comment, and I fixed it.

I pushed the changes and waited for all the checks to run. This took around 20 minutes. After that, I saw several failures. One was code formatting, which asked me to run another command to fix it. I did this a couple of times until most errors were cleared. But then about 40% of the checks failed with no clear explanation.

I asked around and was told to re-run the checks, which we sometimes call flaky checks. This time it passed, and the PR was almost ready to merge.

Merge and deploy

I got the final approval from the team and saw the scary green button saying “squash and merge”. We have an internal policy that you merge and immediately deploy within the allowed timeframes.

I made sure I could do it, merged, and deployed the code. The deployment took another 10 minutes.

At this stage, I just sat and waited to see if the deployment actually worked. It was a bit scary because a failed deployment might mean that the Port MCP server wouldn’t be available to customers. Now, I know it shouldn’t have happened since it passed all the gates, but I still didn’t feel comfortable. Once I saw it finished and verified that my new feature worked, I was relieved.

It’s in production

I opened Claude and Cursor, used the new prompt in each, and saw how both delivered exactly what I hoped for. I wrote the release notes quickly and shared them in our internal Slack channel so everyone knew about it and could start spreading the word.

Conclusions

Every few months, I develop something small in the product to feel the same friction developers live with. It helps me empathize with my team and identify bottlenecks. It also helps me imagine how agentic flows work around us and understand where I struggle, because that’s where an AI agent would struggle too.

It was a great experience, and I recommend it to every product manager. It helps us grow in empathy and understand that when engineers say a small task will take a few hours or maybe a day, it sometimes ends up taking two or three days, even if it’s small. Not because the feature is big, but because delivering a new capability to production is a complicated task.

Overview

I won't explain the term Context Engineering, but I do want to share my take on it, what it relates to, and some concrete examples from the engineering space.

Context gaps

As a B2B prospect, when I look for software, I usually search online. I have a pattern to find the software I think I need or want. I go to its website, see some use cases, and if I'm interested, I raise my hand and wait to be contacted.

At this point, there are some assumptions that only I know about:

1. Why I think I need this software.

2. What are the problems that I believe I have that this software might help me with?

3. What is the value I perceive from this software that might solve these pain points?

On the other hand, there's someone from a GTM team, for example, an SDR, seeing my hand raised, doing a bit of a discovery, and now he's trying to assess additional points -

• What he believes I'm looking for.

• What he assumes are my pain points.

• What is the possible value I might get from the product?

• How to start the sales process?

The different realities

If we were to meet at this point, we'd have a lot of hidden context:

1. What I think my pain points are.

2. What I think this product could help me with.

3. What the salesperson believes my perception of the product would be.

4. What the salesperson is trained on is the value of the product.

5. What are my true pain points?

If we had the discussion today, it would be very difficult to bridge this gap. There are all kinds of different realities that we couldn't talk about - some are hidden, and some are between the lines. It would be very hard to get alignment and action items from such a call.

This doesn't say these calls don't happen. But the usual sales process is:

1. A B2B prospect comes in, wanting to see a real demo and get the price.

2. The salesperson arrives, asks a bunch of questions for 10 minutes, shows a couple of slides for an additional 5 minutes, and asks for a follow-up meeting where maybe they'll see a demo.

Ideal context situation

Let's consider a different possibility. As a prospect, I know exactly what my pain points are and am very aligned with what I need. When I see the product, the value propositions are very clear.

The site is great, the messaging is on point, and I have a live demo. I even signed up, tried it for myself, and verified it can solve my pain points.

The salesperson on the other end has access to my usage data. He has wide and deep knowledge of the industry and where I specifically come from, so he can actually tailor what the product can do for me if I use it more extensively.

Now, at this point, if we meet, the chance we'll get aligned is very high. And a possible discussion would just be to go over a slide or two, make sure we fully understand the picture, discuss next steps, and possibly pricing.

In a way, if I already use the product, and I get it, I love it, I want to buy it, I don't need to see ten slides explaining the history of the company. I just don't.

Transition to Engineering

Let's switch the record and move the example to the engineering side.

Let's imagine I go into one of the generative AI products and just write something like:

Provide the code to fix issue ACME-123.

Obviously, the expected response would be:

I'm happy to help you, but what is ACME-123?

It's not that far from a salesperson, where a prospect comes in asking for a demo. The salesperson is asking, “What are we demoing for?”

Opening a blank GPT chat is like working without context.

Context engineering is how you add your unique context that the LLM is not trained on. It starts with simple prompts and instructions, followed by extensive data access so the generative AI gets the wider picture and eventually achieves higher accuracy with fewer attempts and words.

Context engineering examples

I want to share some real-world examples to make it concrete.

Service ownership

Understanding the owner of a specific service so we can inquire about it and possibly contribute to it. The prompt would be:

Who owns the service checkout in our company?

Context engineering needed:

• Software catalog.

• Team structures and their members.

• Organizational structure.

• The commit history of each service.

• Service README file.

• Recent Jira tickets per service.

• Skill sets of engineers, especially those familiar with frameworks relevant to the service.

Critical incidents

Understanding the production situation in regard to incidents. The prompt would be:

What are the critical incidents we currently have?

Context engineering needed:

• Identification of who “we” refers to (team, company, or specific user).

• Understanding system and service dependencies.

• Awareness of historical prompts and queries from the user to infer intent.

• Access to incident data.

• Incident priority levels.

• Mapping of incidents to related services.

• Identification of which services are considered critical.

• Information on which customers are impacted by current incidents.

Next tasks for today

Helping a developer quickly understand what they should focus on. The prompt would be:

What are my next tasks for today?

Context engineering needed:

• Current workload and task list.

• Incident tickets assigned to the developer.

• Jira tickets assigned to the developer.

• GitHub issues opened in public repositories they own or contribute to.

• Support tickets awaiting the team’s response.

• Overdue on-call action items.

• Open security issues nearing their SLA deadlines.

• Developer’s daily calendar.

• Pull requests to merge or review.

• Prioritization context - company-wide priorities, strategic projects in progress, and teams the developer is part of.

Provisioning cloud resources

In daily work, a developer may need to provision resources (e.g., a new Kubernetes namespace or a new database). The prompt would be:

For task ACME-123, I need to create a new S3 bucket. How should I go about it?

Context engineering needed:

• The task context (description, priority, links).

• Organizational conventions (naming, tagging, environments).

• Who is allowed to provision it, and what is the permission model?

• Required approvals and the approver(s).

• The standard process for this resource in the organization.

• If using direct integrations: the API or step-by-step walkthrough.

• If using Infrastructure as Code: how to author the Terraform file, where it should live, and who should approve the PR.

Conclusions

Context engineering is about making LLMs more useful by giving them the right context to understand where developers are coming from and the ecosystem they operate in.

The challenge lies in providing high-quality context without over-exposing tools or data in ways that create chaos and erode trust, ultimately reducing AI adoption. To me, the concept is clear, but its execution is the true hurdle.

Intro

My team and I used to create monthly changelogs for product releases. The manual process took about a week, with over a day just to gather the necessary information. I built an AI agent in n8n that streamlined this process to be real-time, reducing the time it takes to just a couple of hours.

In this post, I’ll dive into the details of how I did it and why it’s not as easy as LinkedIn makes it sound. When I hear someone say, “AI should be able to do that, right?” I recommend they try it out and see for themselves. The TL;DR is that it was much harder than you would expect.

Let’s dive in.

High-Level Architecture

The business workflow is such that every new feature release is announced internally on our Slack. Instead of gathering everything at the end of the month, the agent picks it up in real-time and notifies in the thread once it’s finished.

The workflow starts with a Slack trigger, then moves to a simple agent with access to broader context in Port (our internal developer portal, which is the product we’re building) and Notion, the tool where the release changelog is written.

The context in Port includes product themes, the owner PM, and some additional context on the release itself. The Notion page is essentially a running list of the month's releases.

To hint at the next steps, here’s how the current flow looks in n8n:

When I’m asked, “How much time did it take to build it?” my answer is, “Probably two to three hours, but that initial time investment grew as I discovered more edge cases and worked to improve its accuracy.”

Similar to my post on building the MCP, building is one thing, but getting it to work is completely different.

Let’s go into the different parts and tradeoffs I encountered along the way.

The Slack Trigger

For the first take, I assumed the AI agent would do most of the heavy lifting in analyzing the message. But then I got this release note:

Pete has joined the channel! 🚀

Happy to announce that Pete is now part of this channel. With this new addition, expect sharper insights, faster feedback loops, and an extra boost of energy—drop a welcome message below!

Confusingly, the workflow was getting triggered when new members joined the Slack channel. The AI model didn't figure out this wasn't a feature release and added it to the monthly changelog. A funny mistake, but an unacceptable one.

At this point, I was faced with a tradeoff that would surface again: invest more time in deterministic logic, or prompt and hope for the best with non-deterministic LLMs.

My solution was to improve the workflow:

• I saw the trigger step had a type and an optional subType property.

• I added an IF section so that for a channel_join event, the workflow wouldn’t trigger.

Like with all development tasks, getting it to work took its toll:

1. Replicating the case with the right trigger (using execution logs and the debug editor).

2. Testing each step separately to ensure it worked as expected.

3. Testing E2E to see if the flow was broken.

I found a few more cases like this (such as message deletions), and I handled them all in a similar way.

Infinite Automation Loop

While still in the experimental phase, I got a message saying I was DDOSing our Slack. A single release note got 50+ replies from the agent in less than a minute.

Here, I learned an interesting fact: sending a message in a thread is also considered a channel message. This created a loop:

Similar to the previous case, I added a step that filters out thread messages. At this point, the workflow looks somewhat like this:

The AI Part(s)

At this point, you might be missing some context on what I actually expected the AI agent to achieve. As it turns out, it was too much to ask from a single prompt, which led me to another tradeoff: one agent with massive instructions versus multiple smaller, more focused agents.

Similar to the previous tradeoffs, and perhaps generally in software, one large function is easier to build but harder to maintain and test, so I went with the focused agents approach.

Here is a list of the agents in the process and the task each had:

1. Type of release - This agent needs to categorize the release into pre-defined buckets based on instructions and historical assignments. The type of release later helps determine whether we need to add it to the changelog.

2. Ownership - This agent gathers product component ownership from Port, categorizes the release message into one of these components, and determines ownership (which is later important for follow-ups on the changelog to add visuals, etc.).

3. Message guidelines - This marketing-oriented agent knows our language, previous releases, and changelogs, and determines how to condense a detailed Slack announcement into a one-liner for our changelog.

4. Release page - While it may sound easy, figuring out the right release page in Notion for the month is not a trivial task (I will elaborate on that below). This agent should output the page ID for the rest of the process.

5. Existing or new announcement - In some cases, we build the release page in advance or send a couple of variations of the same feature in Slack. This agent needs to determine whether the release page already contains this feature.

I believe it's clearer why going with smaller, more focused agents was the right choice in this case, but it also made our workflow much more complicated in terms of different failure points and data flow. I won’t draw it out, but you can imagine how it gets closer to the first workflow screenshot showing the final n8n flow.

I won’t dig into each step, but I do want to cover a few interesting steps and findings I had.

Ownership AI

This AI agent is relatively simple and started like this:

However, the results were not great. I played with different models, but I felt it was something that GPT4.1-mini should be able to do (and thus save cost and time).

After some research and testing, I was able to improve it by adjusting the tool itself, rather than the prompt or the model.

Before the change, it was an array of JSON objects:

[

  {

    “Name”: “frontend”,

    “Owner”: “Matan”

  },

  {

    “Name”: “backend”,

    “Owner”: “Phil”

  }

]

After the change, it was a long formatted string:

##Frontend\nOwner:Matan\n##Backend\nOwner:Phil\n

It seems like the string version worked much better.

Release Page & Existing Announcements

This was the trickiest part and really the heart of the workflow. If you just add everything being sent your way to incorrect pages, it misses the point and creates a burden rather than value.

At first, I had one agent tasked with both finding the relevant page and deciding whether the announcement should be added to it:

The get_pages tool had a search function in Notion with a predefined query (e.g., “release notes - {{month}}”). The agent was able to run it with the right parameters, but I noticed that for some reason, Notion search didn't return the right page or the right order.

For example, a search for “Release notes - July 2025” brought up “Competition - July” as the first result. I tried increasing the number of results (from 10 to 50), but it was both inaccurate and consumed way too many tokens (as the response is a very long, non-LLM-optimized JSON).

After a few days, I had a better idea. I made sure all the release notes pages in Notion were under one parent page (it was a page, not a database) and changed the tool to bring that page's content instead. This way, I ensured the right pages were somewhere in the response. It didn’t solve the token consumption, but at least it worked.

At this point, I still saw many duplications in the release page, suggesting the agent was deciding to add announcements that were already on the page. I looked at past executions and the agent debug logs and saw that the tools did return the right data. You would expect the AI agent to “figure that out.”

I want to pause for a second and return to the tradeoffs I mentioned. The ideal implementation of an AI agent would be cheap, with broad context that requires minimal intervention, and capable of doing a very complex task.

The reality is, you need to compromise and make tradeoffs to get the agent to actually work and provide good results consistently.

I was able to eventually get better results by applying these steps:

Now, some of you might raise a good point: Is this still an AI agent? The final step is just an LLM. That’s true, and I believe the definition of AI workflows and agents isn't binary; you make tradeoffs along the way. If an engineer decides to use a third-party library or an external automation tool instead of writing code, is he still an engineer? Of course, he is. Similarly, the entire flow is agentic and involves the right context, tools, and memory to achieve the task.

Conclusions

Building AI agents is definitely fun and satisfying, but it’s also challenging. Getting them to work in production and provide consistent results is hard. I highly recommend everyone try different frameworks and start today.

Here are my main learnings along the way:

• Start small - While LinkedIn makes it sound like AI agents are ultra-smart AGIs, reality is different.

• Test, test, test - Make sure you have the right framework to test and debug the agent in different scenarios.

• Anticipate changes - The agent will change a lot after you first deploy it, so make sure you have the attention to monitor it and think about unique edge cases you wouldn’t expect.

• You don’t always need a hammer - Sometimes, a simple 4.1-mini LLM step can do the trick. Don’t force the use of thinking models and complex tooling if the task can be achieved with simpler tools.

Domain-specific LLM

AI research companies will need to build large-language models (LLMs) tailored specifically to certain sectors, domains, and industries. This specialization will support high-quality AI agents and drive greater adoption. Soon, we might see models like O4-sales or Sonnet-5-devops. This isn’t a new idea; it’s rooted in the principles of domain-driven design.

It has been more than 20 years since the term domain-driven design was coined, yet I still find it relevant today. To be clear, I read the entire book (as challenging as it was).

One persistent trend is the difficulty we face with language and communication within organizations. That’s precisely where bounded contexts and a ubiquitous language can help.

In the era of AI, these concepts are more relevant than ever. I believe they form a critical part of context engineering. We’ve already learned that good AI output depends heavily on good input. Input, in this sense, includes training data, instructions, additional documents, memory, and more. Yet language, the central component in LLMs, varies significantly between individuals and carries nuances that AI must bridge effectively.

Same word, different meaning

Let’s consider two examples

First example - Dan from Marketing

Dan, a marketing manager, uses GPT daily. One of his goals is to optimize his sales pipeline and automate as much as possible while remaining in the driver’s seat. He uses prompts like:

• “How can I improve my pipeline?”

• “Do we have any new leads today?”

Second example - Jane from R&D

Jane, a senior engineer, uses Claude daily. Her priority is to ensure infrastructure stability, prevent downtime, and maintain fast-paced task execution. She uses prompts like:

• “Why is my pipeline taking so long?”

• “Do we have new leads on what happened?”

Both Dan (the marketing manager) and Jane (the senior engineer) use terms like “pipeline” and “lead.” Although LLMs are trained to recognize context, effective context engineering means minimizing the chance of misunderstandings by providing high-quality input. Therefore, a clearer prompt might look like:

You are a marketing expert, and your goal is to help me improve my lead pipeline. I work as an SDR at Acme Inc. Our leads mainly come from LinkedIn and visits to our website.

I’m a senior engineer at Acme Inc. Help me improve my infrastructure pipeline to optimize velocity. Be highly technical and creative in your solutions.

Without these clarifications, Dan might unintentionally receive a response about deployment pipelines and CI/CD automation, causing confusion and prompting him to clarify further or switch models.

The language barrier

Communication remains challenging with AI. This issue is amplified when autonomous AI agents encounter similar misunderstandings and must determine the correct context to reach accurate decisions. As AI agents increasingly operate across diverse domains, dedicated LLMs for these specific contexts will become necessary.

The solution to communication barriers lies in creating a shared language. This is where the concept of ubiquitous language comes into play. For example, an O3-sales model will understand terms like pipeline, lead, and QBR, while a Sonnet-5-devops model will excel in the CI/CD and Kubernetes ecosystems.

Organizations will face the challenge of clearly identifying their bounded contexts, selecting the models that best match their language, and bridging communication gaps between different departments (and their agents) using “translators.” For instance, when a marketing agent discusses a “pipeline” with a DevOps agent, the system will explicitly clarify what “pipeline” means within each domain.

Summary

The next evolution in communication will focus on improving shared language and terminology between humans and AI applications, and among AI agents themselves. Achieving this will depend heavily on dedicated, domain-aware, industry-specific LLMs.

Introduction

As part of my latest side-project release, I built and published my first Google Sheets add-on. I wanted to solve a problem I faced while evaluating AI prompts and answers at scale. At first, I thought it would be a quick coding project that would take a few hours. But as I went deeper, I realized the real work wasn’t in writing the code. It was in testing, debugging, deploying, and publishing it so that others could use it too.

This post is a look at that process. It’s about how “vibe coding” makes it easier to get started, but taking that code and making it work for others is still complicated. Here’s what happened along the way.

The Motivation Behind the Add-on

The motivation for building this add-on came from my work at Port. I needed to help the team move faster when adding AI features to our site. Specifically, I had to build a prompt for an AI agent and wanted to add example questions and answers for it (evals).

I did this manually - first writing the prompt, then listing expected questions and ideal answers, and finally running each through ChatGPT to see how it responded. It was a lot of manual work and didn’t scale when I wanted to test more than five questions. I found myself constantly updating the prompt, checking if the changes worked, and repeating the process over and over.

I wanted a way to automate this testing and make it easier to understand how well the prompt worked across a bigger set of questions. That was the starting point for this add-on.

What the Product Does

The add-on gives you a template in Google Sheets where you can define a prompt, a set of questions, and the expected answers. With a few clicks, it connects to an LLM that acts as a judge, running these questions through the prompt and returning the answers. It then generates a report showing the accuracy and how well the prompt performed.

The idea is to take what I was doing manually (adding questions, running them through ChatGPT, checking if the answers made sense) and make it scalable and repeatable. Now, instead of testing five questions by hand, I can test 30 or more at once and see a clear report of how each answer compares to what I expected.

Key Challenges and Hurdles

The first challenge was figuring out where to build this add-on. I wasn’t sure if Google Sheets was the right interface or if it should be something completely separate, like a custom app. I knew I needed something that felt like a database but was also flexible and easy to use.

The second challenge was all the backend work. Once the code was running for me, I had to make it work for others. This meant setting up a Google Cloud Project and dealing with all the permissions and APIs that come with Google Workspace add-ons. It wasn’t straightforward, and there was a lot of trial and error.

One thing that added friction was the lack of a native interface of Apps Script (the Sheets code platform) with Claude and Cursor. I had to do a lot of copying and pasting between tools, which was clunky and slowed things down.

I also ran into an error because I was logged into multiple Google accounts at the same time. It took a few deep research and visiting Stack Overflow to figure out this was a common problem and how to work around it.

Finally, getting it published in the Google Marketplace was more complicated than I expected. Google’s review process had its own limitations and took more time than I thought (2 weeks). At each step (building, testing, publishing), I ran into new issues that required me to dig deeper and understand how everything really works.

Exploring Existing Solutions

Before deciding to build my own add-on, I looked for existing solutions to see if they could do what I needed. I searched the Google Workspace Marketplace for AI extensions and found a few options, like Claude for Sheets and GPT for Sheets. Some of them had a formula-based approach, while others were more template-driven.

I installed a few of these add-ons to see how they worked. Some offered basic integrations, but none of them fit my use case without a lot of extra manual work. Some were paid, which I didn’t want to commit to for a quick experiment.

The fact that these add-ons existed showed me that the technology was there; it just didn’t fully solve the problem I had. That gave me more confidence that I could build something better suited to my needs.

Deciding on Google Sheets

I decided to build the add-on in Google Sheets because that’s where I was already doing this work. I was writing questions, expected answers, and running the tests manually in a spreadsheet. Google Sheets was the natural place for it as it’s a lightweight database and was already part of my workflow.

Another reason was that I had some experience with Apps Script, which made it easier to add custom functions and logic. I knew I could connect it to external APIs and build the backend around it.

After testing existing add-ons and seeing they were mostly built on top of Google Sheets, I felt confident that Sheets could be the right platform for my own add-on, too.

Defining the Product’s Scope

At this point, I had a clear picture of what I wanted the add-on to do. I’d say about 70-80% of the scope was already defined in my head. I needed to let users add a prompt, list questions, and expected answers, and then run them through an LLM to see how well the prompt worked.

It also needed to create a report that showed how accurate the responses were, so I could see if prompt changes actually improved the results. I didn’t want it to be complicated and instead be just a few simple steps to go from a rough prompt to a clear evaluation.

From there, the plan was to iterate: build something simple, test it myself, and then see what else was needed to make it work for others.

The Development Timeline

The timeline for building this add-on was pretty straightforward, though not without its hiccups. I started by exploring if there were any similar add-ons already in the Marketplace. Once I confirmed that nothing fit my needs, I started working on a rough prototype using Google Apps Script.

I worked with Claude to help write and refine the initial code. After that, I iterated on the structure and logic until I had something that worked for me. At that point, it was about 70-80% done in terms of the core logic.

From there, the focus shifted to getting it ready for others to use. This meant setting up the Google Cloud project, configuring APIs, and dealing with all the backend details that aren’t obvious at first. I also did some real-world testing with additional accounts to make sure everything worked as expected.

The final push was preparing it for publication in the Marketplace. That part took the most time, mainly because of Google’s review process and some unexpected requirements that came up from it.

Testing and Debugging

Once I had the core logic in place, I started testing it with more questions and different prompts to see how well it worked. Running tests manually was easy at first, but it got more complicated as I added more questions and tried different LLMs.

A big part of testing was checking how the LLM handled the questions and how close the answers were to what I expected. I found a few bugs right away: some answers weren’t being parsed correctly, and some of the logic in comparing answers didn’t work the way I wanted.

Debugging was about going step by step and making sure each part did exactly what it was supposed to. Sometimes that meant adding new functions in Apps Script, and sometimes it meant tweaking the API calls to make sure they were giving back the data in the right format.

Even small changes in the prompt or in how the LLM was called made a difference in the results. So I spent a lot of time going back and forth, changing one thing at a time to see what worked best.

Besides the prompt, I also fixed issues around rate limiting, clearer error handling, and made the user interface more consistent and appealing.

Publishing the Add-on

After testing and fixing bugs, the next step was to publish the add-on in the Google Workspace Marketplace. I thought it would be a quick step; just filling in some forms and clicking “Publish.” But it turned out to be more complicated than expected.

First, I had to learn how Google Cloud actually works. That meant spending over an hour researching how to set it up, including watching three different YouTube videos to make sure I didn’t miss anything. There were settings in the Google CLOUD that didn’t have clear documentation, and I spent time figuring out how to make the add-on accessible to others without giving away too many permissions.

Then, I had to record a demo and fill out all kinds of details I hadn’t thought about before. The first feedback from Google was about the scopes I was using and instructions to avoid certain scopes to get approved. It took three rounds of submissions before I got a link to a much simpler way of dealing with permissions. None of the LLMs I was using had been able to figure that part out.

As part of publishing, I also needed a landing page for the add-on. I built that using Bolt, but deploying it to my domain through Netlify wasn’t straightforward. It required a more complicated DNS setup that took some extra time to figure out. This alone took three days.

In the end, publishing took longer than the actual coding and testing (around two weeks). But once it was done, the add-on was live in the Marketplace and ready for others to use.

Lessons Learned

This project reminded me that building something useful is more than just writing code. While vibe coding made it easier to get started, making it work for others required real curiosity and a deep understanding of the tools and systems involved.

Testing and debugging were harder than expected. Even small changes in the prompt or the API calls changed the results in ways I didn’t always expect. The process of making sure everything worked smoothly—and worked the same way for other people—took time and effort.

Publishing was the biggest surprise. I had assumed it would be just a few clicks, but it turned out to be a real project on its own. Understanding Google’s requirements and going through their review process made me realize that sharing your work is its own skill.

In the end, the most important lesson was that while it’s easier than ever to start building, taking something from “just built” to “ready for real users” still takes real work.

Similar to my MCP building experience, with software, the unknown is always much larger than the known. But that’s also the beauty and challenge of it!

Introduction

Over the past month, I’ve come across the term MCP multiple times—first in internal discussions with my team, then on LinkedIn, and finally in recent product release notes. Since my team and I are actively working on building AI agents, I figured it was worth exploring to see what the hype is all about. I decided to share my experience with adding, using, and eventually building an MCP server.

What is an MCP?

A quick Google or ChatGPT search would probably provide an answer, though I have to admit I was surprised that Claude—Anthropic’s own AI, the company that actually introduced MCP—didn’t recognize the term.

In short, MCP is a protocol that enables AI agents to interact with third-party tools. For example, an AI assistant could fetch data from Jira to answer questions about open issues or even send a Slack message on your behalf. It acts as a bridge, allowing AI to extend its capabilities beyond just text-based responses and custom-built tools.

What Is It Good For?

The first thing I did was look for existing MCP servers I could connect to and see how they might be useful. The easiest place to start was the Claude, as it's the most straightforward LLM to integrate MCP into. I began by setting up a weather server using the sample instructions. This allowed me to ask Claude about the future weather forecast, and it would retrieve and provide the data. Nice, but not groundbreaking—any LLM with web search capabilities could do the same.

Next, I moved on to installing the Slack MCP server. To test its usefulness, I gave Claude the following prompt:

"I used to check the Product Team channel daily to see if there were any updates I needed to address. Could you do that for me and summarize any pending action items?"

After a few searches and attempts—done entirely on its own—Claude provided a summary. It informed me that I had missed five messages and that there was one key action item requiring my attention. Now that was starting to feel genuinely useful.

Taking it a step further, I then asked Claude:

"Could you reply in the thread to the message that requires my attention with my response?"

I provided my response, and Claude handled the rest. In just about three minutes, I reviewed my morning updates in a Slack channel, identified key action items, and even responded—something Claude also helped me formulate. Now this was productivity.

Exploring MCP Servers and Their Potential

Browsing through different MCP server directories, you’ll find a variety of integrations—GitHub, Linear, AWS, Notion, and more. Think of it as a library of APIs, but one that doesn’t require you to write code or fully understand API contracts. Instead, your AI assistant can integrate with these services, fetch data, and take action on your behalf.

Consider some practical use cases:

• "I have this PRD in Notion—here’s the link. Can you review it and suggest improvements?"

• "This is an EPIC in JIRA, and we're building a test plan for it. Can you suggest five test cases for each user story?"

MCP cuts the need to manually navigate APIs by simply issuing natural language commands. It makes AI-driven workflows significantly more accessible and efficient.

Building My First MCP Server

When speaking with key customers about interacting with AI agents, a common theme kept emerging: meet developers where they work. We repeatedly heard requests for VS Code extensions, plugins, or even Slack apps—tools that seamlessly integrate into existing workflows.

The MCP server presented itself as a potential quick win, allowing us to connect Cursor and support GitHub Copilot while integrating our platform into these developer-centric tools. Imagine interacting with our product over the platform with simple queries like:

• "What was the latest PR merged in the payment repository?"

• “Why is this service failing to meet the desired security standards? Suggest action items”

That alone is useful, but doing it directly from your IDE while connecting to other servers? Now that’s a real productivity boost.

Figuring Out Where to Start

Anthropic provides a quick start guide—which, to be honest, isn’t all that quick to start with. It took me some time to go through example repositories, review open-source code, and have multiple conversations with both Claude and ChatGPT before I finally settled on an approach.

I decided to use two example repositories as a foundation and worked with Claude to generate the initial boilerplate code. From there, I ensured my server's structure followed best practices, particularly for a Python-based MCP server.

Writing the core logic for the MCP server, given the boilerplate, wasn’t particularly complex. I even leveraged the recently published PyPort SDK, which made the process fairly straightforward.

The only real challenge came from the fact that the AI agent now operates asynchronously. Instead of simply handling a POST request via a REST API, the flow became slightly more involved. However, even with this added complexity, the implementation itself was still manageable and took no more than 20 minutes to complete.

The real challenge? Testing and deploying it.

Testing and Debugging

Following the MCP server documentation, I configured the server to run and connect it to either Claude or Cursor. However, when I first attempted this, I kept running into errors—the server simply wouldn’t start.

One key difference between the two tools is Claude’s built-in logging interface, which stores logs from the initialization process. Cursor doesn’t provide the same level of visibility. This meant I spent about an hour manually copying logs from Claude, pasting them into Cursor, and debugging the issues.

Ultimately, the problem boiled down to how the MCP server handles authentication arguments and environment variables. I later discovered that many others struggle with this as well, and some directories are even trying to bypass the issue by offering managed MCP servers that take care of authentication and configuration for you—like Composio.

How did I finally figure out the solution? Using OpenAI's deep research feature, which identified a very niche suggestion in a Reddit thread.

The feeling of asking Claude or Cursor a question and seeing it successfully trigger the AI agent we built was enormous—a mix of excitement and relief. It was a clear validation that everything was finally coming together.

With the server working, I was ready to publish it. However, it turned out to be more time-consuming than expected—taking even longer than the actual building and testing process.

Publishing the MCP Server

When looking at how other MCP servers were built, I decided to package mine using uv, Python’s package manager. I already knew the installation command, but I relied on Claude to walk me through the steps to properly package and publish it.

The process was relatively straightforward:

1. Create a PyPI account.

2. Register the package.

3. Bundle it with a uv.lock file.

4. Run a series of packaging and publishing commands.

That was it—or so I thought.

Similar to the testing challenges, when running commands via Claude and Cursor, the server failed to initialize due to authentication and environment variable issues. After hours of debugging logs and iterating, I decided to switch from environment variables to passing arguments directly. This was mainly due to Cursor’s limitations in handling environment variables during installation (which Composio for example solves).

Finally, after several iterations, it worked! The MCP server was now published, and others could install it.

But publishing it for myself was one thing—getting others to successfully use it was another challenge entirely.

To ensure it’s production-ready, I worked with two colleagues to test the installation process using the same commands I had documented.

• First test: A small typo in the installation instructions caused an issue, but after fixing it, everything worked smoothly.

• Second test: This one was more challenging. As package managers and different Python versions were already defined, we had some compatibility issues.

To resolve this, I turned to Claude once again and created a shell script that automates the setup, making it easier for others to install and configure the server without running into environment conflicts.

With that, I could finally consider my work done—our MCP server was built, tested, published, and ready for others to use.

Lessons learned

This experience reinforced the power of AI-assisted development and how much ownership product managers can take over technical solutions. My main takeaways include:

1. AI is not a magic bullet: Complex problems still require deep research, trial and error, and critical thinking.

2. Testing and deployment were the hardest parts: Cursor offered little support, requiring multiple iterations before success.

3. Making it work for others is a different challenge: Enterprise users expect stability, and ensuring compatibility across environments is not trivial.

Despite the challenges, this was a fun and rewarding experience, proving that even new, uncharted technologies can be tackled and brought to life.

Introduction

Some time ago, I wrote about why product managers need to code. However, it wasn’t a deep dive; it was more of a tip or a suggestion. Recently, I took on a task for an internal tool improvement and built it from scratch. From this experience, I learned a lot about what it means to develop something, and how to better understand developers. In this post, I will share a deep dive into the process I went through, as well as the lessons I learned.

Task background

To keep things simple, the task was about integrating data between two third-party services. In one system, our product team manages customers’ feature requests and general feedback. The other is our company’s CRM that houses all our customer data. The goal was to create better views and a smoother management experience for feature requests in the context of customers.

For example, being able to see, for each company, which feature requests they submitted, as well as identifying the top feature requests by total company votes and ARR (annual recurring revenue). This context cannot be achieved easily—if at all—in the existing product where we manage our feature requests. The task was about integrating the data so we could create these views.

Lessons learned

As the post will explain, this project took longer than I originally planned (and so did writing about it). For that reason, I’m including the lessons I learned upfront:

1. Development is Iterative - Each cycle revealed more about the scope, limitations, and allowed me to refine my estimations. What I imagined before starting was vastly different from what it became by the end.

2. Estimation vs. Reality - Estimating is easy; being accurate is almost impossible. Focusing on the scope, goals, desired state, and making tradeoffs along the way was the best way to influence the timeline.

3. Balancing Perfection and Delivery - Owning a project makes you want to perfect it, but it’s a challenge to balance releasing something fast that works—even with potential flaws—against the desire for perfection.

POC

The POC stage was about validating what was possible and what it would require from a technical point of view. Since I needed to work with two third parties, the first step was to obtain access to each, understand their API documentation, and see if I could interact with their APIs. Luckily, for one of them, I was already familiar with its API, so that part was pretty straightforward. For the CRM, I had no prior experience. I needed to work with our CRM manager to get access and some basic knowledge, and then, using GPT and their API documentation, I was able to authenticate with their API.

The next step was to identify what I actually needed to do: what data to map, which objects to handle, how the data related to one another, and how to address duplication issues, among other things. At this point, I didn’t know all the open issues or questions, but that was acceptable for a proof of concept, where the main goal was simply to confirm that I could integrate with the two APIs and move data from A to B.

I also looked for an SDK for each API and successfully found one for the CRM. That came in handy when I needed to create a more complex integration. I finished this step with a better understanding of feasibility and started to get a sense of the scope of the task.

Technical design

At the POC stage, everything was local in my own repository and didn’t include any integration with existing infrastructure. In reality, the integration needed to sit somewhere, which meant a service had to host it and run it on the schedule we decided. The goal of the technical design phase was to determine the best way to integrate the two systems within our current infrastructure, now that I had confirmed they could be integrated.

I started by getting access to our development repository and discussing the best flow with the DevOps team. They suggested creating a specific folder for the code and using a GitHub workflow. This setup also dictated how the code should be built, what it should consume and output, and provided insights on troubleshooting and optimization I might need to include down the line to detect any issues.

This step was relatively short—taking a little more than a day. Looking back, I believe I was only about 10–15% of the way through completing the entire task at this point.

The first development iteration

Now the fun begins. I got access to the repository, created my own branch, and started developing the integration. I won’t go over every step in detail, but I will note that I relied heavily on Cursor—the Chat, the Composer, and the Agent—which was probably the main enabler for completing this task in a reasonable timeframe.

The scope of the first iteration was the “happy flow.” I didn’t focus on performance, optimization, error handling, or duplication yet. Instead, I just wanted to validate that what worked in the POC would also work in the real environment. Concretely, I took around 10 feature requests from the feature request system and synced them one by one to the CRM without any optimization, mostly relying on debug logs.

Looking back, this step was one of the hardest because it established the infrastructure and assumptions for future use cases. The decisions I made here affected later iterations, even though I could have refactored further down the line—but it would have been harder as the code got more complicated than I thought.

Identifying missing use cases

Once the integration was up and running, I started to notice various missing use cases. A feature request might already exist in the CRM, and I might need to update it rather than just create a new entry. Simply creating a feature request wasn’t enough—I also needed to associate it with the company and the user who submitted it. Sometimes, when pulling a feature request from a third party, certain fields are null, which can cause errors.

Moreover, some parts of the code were not optimized. Running on 10 feature requests took about half a minute, which could translate to hours for an entire database. This was just the tip of the iceberg, and I didn’t have any organized requirements document. Instead, I shared daily updates via a Slack channel, always including the next steps or tasks I identified. The more I worked, the more additional scope I found.

The first iteration was successful in that it worked, proving I had the skills to move forward. However, it was clear that I needed to continue implementing these missing use cases.

The second development iteration

The second iteration focused on implementing the missing use cases and preparing the integration for production readiness. This involved optimizing network requests to avoid rate limits, properly logging errors, and adding visibility into the process. If I’m integrating two third-party tools daily without knowing what actually happens—even if everything appears successful—it’s bound to become a problem later.

During this phase, while I still relied heavily on Cursor, I noticed its limitations as the codebase grew larger and more complex, containing multiple files and modules. For example, when I wanted to implement a new flow, Cursor often rushed into suggestions that didn’t align with my technical vision. To address this, I had to revisit my prompting techniques. I made sure to ask it to thoroughly analyze the code, understand the business logic, and treat the flow as intended. When needed, I corrected it and refined the prompts until we reached a decision together on the implementation.

As the code and business logic became more intricate, I had to get more involved in verifying everything worked as expected. This included regularly running end-to-end tests and executing the code from scratch to ensure nothing broke. By the time I completed this step, I believe I was 70–80% done. The integration was running, optimized, and included monitoring and logging for processing larger batches of feature requests end-to-end.

Unit tests

Unit tests are designed to test individual modules or functions in isolation, without running the full flow or interacting with third-party services. For example, I had to write business logic to extract the domains of users who voted on a feature request, filter for unique domains, and sync those to the CRM. This is a self-contained module that could be tested independently of the rest of the code.

For such cases, I built unit tests. I had to consider various scenarios: multiple domains, a single domain, missing email fields, and more. This ensured the code was resilient and handled errors while adhering to the business logic. While I manually tested these cases earlier, unit tests served as a fail-safe, catching unexpected issues that could arise later.

Although I wrote unit tests throughout the process, at this point, I paused to ensure that all internal functions and modules were properly tested. I also added some basic testing for external interactions by mocking third-party services. While mocking is inherently limited, it allowed me to have at least some safeguards in place. This became particularly important as the codebase grew more complex, and I wanted to ensure I wasn’t overlooking anything.

Finalizing the desired scope

The final step was about clarifying the deliverables based on everything completed so far. This meant solidifying decisions such as running the integration in a GitHub Workflow, printing a summary of how long the process took, breaking down the actions performed, and sending this summary to a Slack channel. It also included defining the scope we could handle, understanding the system’s limits, specifying which fields we would sync, identifying the environments we would work on, and so on.

While most of this had already been implemented, this step was about scoping and finalizing what would eventually reach production. It gave me clarity and confirmed that I was around 80–90% ready with the code.

The third development iteration

The third development iteration was simpler and shorter, with what I can only describe as a miracle. When I ran the dry run for the first time, it encountered a bug or two, which I managed to solve within two or three hours. And that was it—it worked. I was quite amazed at how smoothly it went.

I repeated the process several more times, using different variations, and it continued to perform as expected. At this point, it was time to finalize everything and align it with the infrastructure. This included building the GitHub workflows, ensuring everything worked locally, and beginning preparations for production deployment.

End-to-end testing

At this stage, I wanted to test the integration from a local instance using the production environment. My assumption was that if it worked in the sandbox, it should work in production as well. Unsurprisingly, it failed. There were notable differences between the sandbox and production environments, such as discrepancies in IDs, schema variations, and differences in how the environments were structured.

To address these issues, I worked closely with our CRM manager to resolve the discrepancies. In some cases, I had to adjust the code to account for differences between the two environments. Each fix was accompanied by linter checks, unit tests, and end-to-end testing on both environments.

While this process took longer than expected, by the end of it, the main code was stable and ready for the next step.

Bug fixes

At this point, I faced a dilemma—a trade-off between perfection and speed. On one hand, I wanted the code to be perfect: well-structured, clear, simple, and thoroughly tested. On the other hand, there was a push for a shorter time to market. I realized this is a common challenge for engineers. Once a feature is released, attention typically shifts to the next task, and unless there’s a critical bug, the released code might not get revisited.

Despite the pressure, I chose to invest time in improving the code during this phase. I focused on making the code more readable, ensuring there were enough logs to identify and fix potential bugs, and testing thoroughly. This phase also revealed bugs that weren’t apparent earlier. For example, just a day before the code was set to reach production, I discovered a critical issue: when updating a specific object, it didn’t work as expected and caused undesired behavior in the CRM.

Through this experience, I learned that finding bugs early is often more difficult than fixing them. This phase was dedicated to properly testing, fixing bugs, and covering as much ground as possible to ensure the code was production-ready.

Monitoring and visibility

Monitoring—particularly visibility into what the code is doing—was a concern throughout the process, but by this point, I adopted a more structured approach to ensure the application’s actions were well-documented and communicated. Ultimately, this meant refactoring parts of the code to ensure the statistics were accurate and building a system that relied heavily on tracking and reporting the integration’s operations.

I implemented a feature to send detailed summaries as Slack messages. These messages included key metrics such as the time taken for the process, the number of API requests, and the objects identified, created, or updated. Without this step, no one would have known what the application was doing, leading to potential assumptions that it wasn’t functioning properly.

Adding visibility not only provided transparency but also gave me valuable insights into the system’s behavior—such as update frequency, latency, and the overall performance of the code.

Preparation for production

In preparation for production, I performed a final full sync between the systems using the production environment and shared the results with key stakeholders, including the CRM manager, product team, and GTN teams, for review. While the code wasn’t technically on production yet, the data was live. I ran the next couple of syncs locally from my computer to catch errors early before fully transitioning to production.

This phase highlighted a familiar challenge for me: navigating the process of integrating code into the main branch (where the production code lives), the Pull Request process (requesting approval for the code integration), and understanding where everything fits. I had to ask a team leader where to place the code, realize I lacked the necessary permissions for the repository, request those permissions, and deal with a new repository structure that differed from what I was used to.

Once the code was in the correct location, I built the GitHub workflow file (a format to automate tasks within the repository). Here, I encountered another challenge—there’s no effective way to test a GitHub workflow file until it’s already on the main branch. This meant going through the pull request review process. Since this was for an internal tool that didn’t impact customers, the review process was relatively quick and lean. However, I know many developers face lengthy review cycles with numerous comments, sometimes taking days or even weeks. I got lucky this time—my code was approved and merged into production.

Even though the code was on production, it didn’t work perfectly yet. I spent a few more hours iterating, ensuring everything functioned as intended, including secrets management, Slack notifications, and the complete working process.

Launch

Launching the new process and integration was straightforward. An automated process now runs every few hours, syncing data between the two third-party systems. It also sends a clear message summarizing its actions, making monitoring effortless. Internal teams quickly noticed the improvement and provided very positive feedback, along with suggestions for further enhancements. It was a gratifying moment to see the results recognized and appreciated.

Monitoring for performance and stability

The maintenance phase has just begun, but for this type of internal tool, I’m confident we have the basics in place to monitor performance and stability. I’ve also started maintaining a to-do list of improvements I’d like to make in the code. Whether I’ll get to those items remains uncertain—probably about as likely as any other developer addressing their personal backlog of desired code refinements.

That said, this project has been a great experience. Not only did it allow me to promote and deliver a successful side project, but it also made a meaningful impact for the broader teams.

Introduction

There is a famous Israeli movie that has the quote: “Start as fast as you can, and gradually pick up the pace.” I want to tell a story about how the exact opposite happened to me and what I learned.

My side project experience

I worked on an interesting side project in Python. For the first day or two, I started with small PRs and small commits—one or two files at a time—always making sure the functionality was there and the code was tested. However, at some point, I needed to revamp everything to reach a viable version, my V1.

To do that, I needed more functionality, modules, and an improved project structure, and every step I took broke something else. If I changed the structure, the tests failed. If I improved the tests, I found issues in the source code. This back-and-forth went on for two or three days, touching around 15 files that completely changed the project’s structure. Moreover, all the changes were only in my local history—in my local branch, not in the remote one. I didn’t push the code at all.

Finally, when I reached a working state, I tried pushing my code, but I had a small violation around a file that should have been added to .gitignore. Unfortunately, it was already committed to my local branch. For those who don’t swim in the technical details, this practically means I couldn’t sync what I had on my computer with what I wanted in my GitHub repository.

I wasn’t sure how to fix that, and while experimenting with changes, I ended up reverting all the work done in all the files since the last push to the remote branch. Yes—two or three days of work were practically lost.

After a few conversations with Chat GPT and pulling my hair out (not that I have much), I found a Stack Overflow post in the nick of time. It explained a somewhat cumbersome but achievable way to restore everything from my local history in VS Code. Long story short, my project is now up and running, and I managed to overcome this huge risk of losing everything I did.

Lessons learned

I believe the main lesson here is about the Big Bang approach. Even though I started small—and recalling the phrase about running as fast as you can—I tried to build the best version that worked, but it came with a huge risk. I don’t think this applies only to code or projects in general; I can think of several areas it might affect.

Working in iterations, providing small changes, and keeping short feedback loops can benefit many situations. This experience strengthened that belief for me.

Practical example

Feature release

As product managers, we discuss features and their scope a lot. We always try to balance bringing some value to the customer with making a version that’s relatively easier to build and release. However, we don’t always consider the milestones along the way, even if they don’t reach the user.

For example, imagine a feature around creating a new marketplace for applications in a B2B SaaS product. The final release might include a marketplace page with lists of apps, integrations, and some install mechanism. Maybe that’s the minimum viable version for customers. But to avoid a Big Bang, show progress, mitigate risk, and boost morale, you need milestones that have significant impact—even if they’re internal.

Maybe the first milestone is showing how a single integration installs (available only to internal employees). Then the next milestone might be showing the marketplace page with just one integration. It could take another month to add the ten integrations you ultimately need, but everyone can see incremental progress, give feedback, and stay engaged throughout.

Projects

Sometimes we have large projects at work that involve different departments and have ambitious goals. We must work backward with first principles in mind, identifying the next checkpoint and ensuring each milestone is acceptable. One example is a company restructuring its organization. One option is for leadership to go off-site, figure everything out, and announce it in one Big Bang. In certain cases, that makes sense.

However, in most cases, you want to onboard employees, gather feedback, and engage everyone. The way to do that is by short feedback loops and small iterations. Perhaps you start by sharing the goals and current pains. Then you gather feedback on that. Next, you show the plan for achieving the new structure—what meetings you’ll have, what decisions need to be made. By the time you finalize the structure, employees feel more connected and informed.

Personal skills

It’s easy to say, “I’m going to learn a new language,” or “I want to code.” When the end goal is far away, it’s hard to stay engaged and motivated. Thinking back to my project experience and almost losing my code, imagine learning a new language: the first milestone might be counting from one to twenty and sharing it with someone (like syncing to a remote branch). Then maybe you learn how to order a coffee in that language and actually do it at a coffee shop. Keeping these small milestones and feedback loops ensures you spot errors—like a wrong accent or approach—early on, not at the very end.

Closing thoughts

While all of these examples sound obvious, I personally failed to follow them in my project, and I’ll likely slip up in my professional life too. Still, this has been an important lesson for me, and I hope it helps others.

Coming back to the famous Israeli movie, I want to claim that the way to succeed is by consistently taking one step at a time.

The dilemma

AI in general, and GenAI specifically, are common trends and buzzwords. Recently, I was involved in several discussions about how to treat them in our roadmap. For example, a theme like “Add AI to the product” is poor as it discusses the solution without any context regarding the problem. Alternatively, using AI to solve a theme like “Improve retention” could make it seem as though AI is treated as a side project.

So, what should we do? Should we take the problems we identified so far and see where AI might help? Or should we focus on AI and discover whatwe can do with it?

To address this question, I drew on Henry Ford’s analogy.

If I had asked people what they wanted, they would have said faster horses.

AI, in this case, is like building a car—a transformative technology that changes the market entirely. However, I’m not a fan of clichés. Instead of stopping here, I decided to look at other technology trends to understand how they fit into this perspective and how to resolve my conflict.

Technial references

Microservices vs. Microfrontend

Microservices are something I see as disruptive technology. In the old days, everything was monolithic. Software products had one codebase. All the code was in one repository, and everyone contributed to that codebase. Eventually, that codebase would turn into the final product for the customer.

Microservices approached the complexity and maintenance challenges of monoliths in a completely different way. They abstracted the dependency and collaboration challenges by allowing the creation of multiple services, each focused on a specific context with limited ownership, while communicating with other components through defined interfaces.

This solved the problem but created an entirely new market. Suddenly, companies had tens or even hundreds of microservices to maintain. This shift required new infrastructure, new ways for services to communicate with one another, and new skills for developers. Previously, developers didn’t need to deploy or create new services—those were already part of the monolithic system. Now, developers had to manage things like service-level agreements (SLAs) and figure out how services should communicate effectively, such as through REST APIs.

Micro frontends, on the other hand, are more of an optimization than a disruption. They take the principles of what microservices achieved on the backend and apply them to the frontend. With this approach, codebases are simpler, and teams are more independent in deploying and utilizing the tech stack they want.

However, the challenges remain largely the same. While microfrontends solve similar problems slightly better, they don’t open up entirely new markets or business models the way microservices did. Instead, they represent an incremental improvement in managing complexity rather than a foundational shift.

Internet and cloud computing

Looking in a different direction, the Internet itself was arguably one of the most disruptive technologies ever, opening up an entirely new world of possibilities. However, advancements like 4G and 5G, while impressive, are incremental improvements. They enhance the existing infrastructure by providing faster Internet and greater accessibility, but they don’t change the market.

Cloud computing, on the other hand, represents a critical shift that reshaped the industry. Before its introduction, launching an online business or offering software came with the significant overhead of purchasing and maintaining infrastructure, such as servers and physical machines. This was a major blocker for many businesses.

Cloud computing removed this problem entirely, introducing a new way of working. In just a few minutes, you can now have a virtual server hosting your solution anywhere in the world. This transformation reduced entry barriers and created a new type of business.

How to identify a disruptive technology

When considering AI, and generative AI specifically, we need to evaluate just how disruptive it will be. Is it solving existing problems better, much like Henry Ford’s notion of “faster horses,” or is it creating entirely new markets and business models, maybe even a “Tesla”?

To answer this, I propose assessing AI through the following factors:

1. New Markets and models: Does AI create entirely new markets, product lines, or business models within its segment?

2. Surface New Problems: Are there problems we hadn’t previously considered that AI now enables us to solve?

3. Obsolete Problems: Are there issues we currently face that AI will render irrelevant altogether?

These questions are important, as they can help us shape how we integrate them into our strategies and roadmaps.

My answers

I’ll admit to having a bit of imposter syndrome here, but my honest opinion is “yes” to all three questions.

First, there are undeniably new markets emerging: AI agents, generative AI platforms, and AI-driven ecosystems that didn’t exist before. These developments have also created new opportunities, such as the growing demand for faster and more capable processors and the significant rise in GPU usage.

For the second question regarding the new problems AI surfaces, it brought up privacy, intellectual property, and ethical concerns, to say the least. Over time, I believe these areas will have their own models and businesses.

As for the third question, obsoleting problems, definitely. I’ve experienced it firsthand. When I worked on a side project, I used to struggle with deploying it. Tools like Replit now abstract away the complexities. Similarly, in my past work on automations, I often faced challenges in finding the right steps and setups to achieve my goals. Now, with just a simple prompt, the solution is built right in front of me. I no longer need to be as knowledgeable or spend as much time figuring it out as I did before.

My conclusions

So, what does it all mean? In my opinion, it means that we need to view AI, and generative AI specifically, as a strategic opportunity we must position ourselves against. It’s not just another technology to solve existing problems; it’s a fundamentally new way of thinking that brings with it an entirely new type of problem-solving. To truly succeed, we need to consider not just the problems of today but also the problems of tomorrow—and the solutions of the day after.

For example, consider the context of e-commerce. It’s not far-fetched to imagine a future where my smart home knows my refrigerator is nearing the end of its life. It could proactively send me a suggestion for a replacement, and with a single click, the purchase is completed, and the new refrigerator is delivered and installed a few days later. This is a problem that doesn’t exist today but very well might tomorrow. Where would this position physical stores? Search engines? Technicians?

Another example comes from the travel industry. Today, the process of finding the cheapest flight ticket sustains an entire business model. However, in the future, AI agents that bid, crawl, and negotiate on my behalf could eliminate that market entirely. Companies and products must evolve to meet this new way of thinking.

I’m not suggesting that AI is the answer to everything. It certainly has its downsides and limitations, many of which we’ve yet to fully understand. But that doesn’t change the fact that it’s here to stay. It’s a disruptive technology that will revolutionize our lives, and to stay ahead, we must ride the wave and adapt.

Why does cost matter?

Cost is a critical aspect of a product. To achieve product-market fit efficiently, you need to balance both income and value. Revenue represents value, but keeping costs low is equally essential. For example, if customers are loyal, valuable, and pay a decent amount, but acquiring them costs ten times their value, scaling becomes inefficient. Similarly, a feature with high usage that users enjoy might not be sustainable if the associated resource costs are too high.

When planning a product roadmap, the impact of a feature is just one side of the coin. The effort and maintenance it requires are the other. While it may not be a glamorous topic, cost is something we need to be mindful of and optimize when it makes sense.

How I started my site

A few years ago, I decided to build my own personal site—a space to showcase my work and share my thoughts. Later, I moved my blog to Medium and then to Substack, but that’s a story for another post. When I began this project, I naturally considered costs and chose what seemed reasonable at the time: a WordPress editor site hosted on a shared hosting plan. The cost was relatively low and billed annually, but it was still a recurring expense. As with other SaaS or online tools, the cost goes up over time, and mine had increased from ~$120 to ~$145.

A few months ago, I came across an interesting post about the cost of AI and strategies to reduce token expenses in products utilizing ChatGPT. This got me thinking about whether I could reduce the cost of my site and what tools I could leverage to achieve that. My main options were either finding a cheaper hosting plan or building a site from scratch with code and finding a simpler hosting solution. At the time, I didn’t want to invest more effort than I already had, so I simply assumed I would have to stick with the status quo.

New site, lower cost

Then, I came across v0. I had used it for some prototyping at work and thought, why not go all in and build a full site? I started experimenting with the free version and ended up creating something I truly liked. I decided to pay for the full version, which costs $20 a month, and began iterating to create a static site to replace my existing one.

At that point, I wasn’t sure how I was going to deploy it. So, I turned to my AI co-pilot, discussed the options, and discovered that Netlify offers a free hosting solution that matched my usage. I wasn’t entirely confident it would work, and I knew part of the process involved configuring a DNS from HostGator to Netlify. Honestly, the word “DNS” intimidated me. But I figured, why not give it a try?

The plan was straightforward:

1. Get the site to at least 80% of my desired result in v0.

2. Deploy it on Netlify.

3. Attach it to my custom domain.

Prototype

Working with v0 probably took the most time. It wasn’t difficult, but it required effort to communicate my vision to the AI—explaining what I was trying to achieve and the design I wanted. I shared screenshots of inspirational sites, provided videos, and gave custom instructions. It took about 20 to 30 iterations before we arrived at something I truly liked.

Once that was in place, the design system was ready, and we began personalizing it by incorporating all the text, images, and unique elements from my current site. Eventually, I had the homepage finalized. Like a good product manager, I understood that an MVP has to start somewhere, so I moved on to step 2 before building the other pages.

First deployment

I opened an account with Netlify, and it probably took me an hour or two to get everything working. I had to create a new Git repository, clone all the work I had done in v0 into it, ensure it had the proper build commands, and link it to Netlify.

It took some time to figure out the exact configuration required, mainly because, while v0 excels at creating Next.js applications, it doesn’t adhere well to standard directory structures or best practices. At one point, I even turned to YouTube and found a video showing a configuration someone else used, which finally resolved the issue.

With that, I had my site successfully deployed on Netlify. It was solid proof of concept that I was moving in the right direction.

Transferring the domain is reversible, but it felt like a danger zone I didn’t want to mess with until I was confident my site was ready to handle traffic. In a real-world scenario, there would likely be feature flags or other precautionary tools to manage such transitions.

Full working prototype

There were still issues with the homepage, like v0 using an online image I had uploaded instead of a static one from the assets folder. I decided to tackle that later since addressing it would cause a drift between the v0-generated code and my own. I continued working with v0 to build the new pages, ensuring the directories were structured properly and components were separated where relevant.

Finally, the site was complete in v0. I tested it for mobile compatibility, though I decided to overlook errors and linting issues for the time being. With that, I moved on to step 2.

Making the site production-ready

Working locally, I had to ensure my Git repository was in good shape—no console errors, no linting errors, and all images generated and loaded statically from the assets folder. While I had the technical knowledge to handle this, I used Cursor AI to assist with some of the changes, either by making adjustments directly or by following its guidance.

Thanks to the use of AI, this step took only about 30 minutes to ensure linting tests passed, the build succeeded, and the site was fully functional.

Now for the final step. It didn’t take much time, but when I changed the DNS, it felt a bit like I was breaking the internet. However, the next day, I woke up to see my new site live and running on my custom domain. At that point, I also disabled the renewal of my hosting plan with HostGator.

Overall, the entire process took me around 3 to 4 days.

Cost saving

So, how much did I save? My previous hosting plan with HostGator cost around $145 annually. With my new setup, I subscribed to v0 for one month at $20, and my hosting with Netlify is currently free. That’s a savings of approximately 85% annually, all while delivering a more flexible and modern site.

There are still some downsides, such as the lack of built-in plugins like Analytics and Google Console, or a lack of support. However, with the free versions of Cursor AI, ChatGPT, and Claude.ai, I have enough resources to figure out what changes I need to deploy.

Conclusion

A good product and result need a balance of effort and cost. The more we pay, the more value we expect. Reducing costs can boost satisfaction without sacrificing quality.

Intro

Someone I appreciate used to say that the only constant is change. To ensure a team or organization achieves its goals, it needs to be dynamic and willing to adjust structures and processes to the changing reality.

Software faces a similar challenge. Features keep being added, libraries are updated, technology changes, and throughout all of this, you need to make sure that everything works as expected.

I thought about how different testing approaches could shed light on how organizations and teams can test their structure, processes, and culture, and make sure they’re on the right track.

Unit testing

A unit test is a way to test a specific component in a specific scenario. It doesn’t mean the entire software works or that it will interact with other components, but this specific component in this specific scenario works.

Yesterday, I installed a bell on my kid’s bicycle. Unit testing meant I first tried the bell and saw it works—it rings. It doesn’t mean it connects to the bicycle yet; it doesn’t mean it’s positioned in a way my son can ring it, but I know this specific bell is working.

Similarly, thinking of product teams, a unit test could be whether a specific PM can write a compelling user story. It doesn’t mean it will get implemented, or the developers will understand it, or that it works for the entire product team, but this specific PM can write a specific user story.

Integration testing

Integration testing starts checking the communication between different components. Each component on its own passed the unit test, but that doesn’t mean they communicate well.

As an example, you could build a roof with Lego bricks and a house with the same bricks. Each on its own looks great, but they don’t connect because their sizes are not exactly the same.

Following the thread on product teams, an integration test could be to take the user story that the PM wrote and run it with the development team. See if it meets the other end and if the developers can collaborate on it and implement it.

E2E testing

End-to-end testing mimics a real flow that the user could potentially experience. Following the examples above, it could be riding a bicycle while ringing the bell or building a full house using Lego bricks.

To draw on the product example, end-to-end tests could be the full product life cycle: discovering a new idea, prioritizing and planning it, building the user story around it, implementing it successfully, and launching it.

We tested each component on its own and tested different components’ integrations with one another, but now we are simulating a full end-to-end flow of the process.

Acceptance test

An acceptance test usually means that someone outside of the team who built the software tests it on their own terms and accepts it. Common examples include a PM testing a feature or a customer participating in an alpha group or usability tests.

The difference between end-to-end and acceptance testing is that end-to-end runs from the point of view of those who built the software, while acceptance testing is from those who use it.

Going back to the product team example, an acceptance test could be seen as a peer review effort, a kick-off meeting with stakeholders, or a general review of the product work process with the organization.

Acceptance tests are important because, at the end of the day, we build software for our users, just as we build processes and culture to meet our goals.

Load test

Load testing is conducted when everything works as expected, but we don’t know to what scale. It could mean running millions of requests to a service or looping through a process in parallel on a scale we haven’t seen yet. This type of test is crucial to make sure you meet the demand and have a resilient product.

In an organizational context, load testing could mean ideating and thinking about whether your current process and structure could handle being 2x, 5x, or 10x larger.

For example, if we have a team of five engineers and one QA, where everything goes through the QA, what would it look like if we had ten teams or if we had ten engineers in a team?

Alternatively, assume as a VP you’re running a planning meeting every two weeks with each team, and you have three teams. Would it work with ten teams?

Load testing your structure and processes is a way to make sure you’re setting up your organization for success in the future.

Smoke test

Finally, a smoke test is a type of test to see if a certain process or service is up and running. For example, every 15 minutes you might want to check if your signup process works. You don’t check its logic, its scale, or its end-to-end flow; you just want to make sure it’s available for users.

Similarly, a smoke test could be a heartbeat or a retro where you assess whether your current process, structure, or task is available and working as expected.

Some examples include checking a Jira board once a day to see tasks in different statuses, randomly picking a user story to see if it has valid content, or choosing a team once a week to join their daily stand-up.

These are ways you can check the pulse of the organization and its processes to see if everything works as expected. If it doesn’t, additional testing methods are required.

Conclusion

To conclude, software and products in general have similar concerns to companies and teams. They need to make sure they work efficiently, at scale, adapt to changes, and serve the end-user needs or goals.

I went over some popular testing strategies, and hopefully you got an idea of how to improve your visibility into your organization or team.

Introduction

I recently engaged in discussions around data strategies like ETL, reverse ETL and ELT. These buzzwords play a significant role in the data world. When you think about it, data is all around us—it shows up in project tracking, pull requests, and online courses. Given that nearly everything we do involves some form of data exchange, what can we learn from these strategies to improve how we handle data and ultimately become more effective?

Decision-Making with ETL

When we need to make a quick decision, we usually know what outcome we’re aiming for and what data we need to rely on. In these cases, we can use ETL, the most basic and common approach. ETL stands for Extract, Transform, and Load. It consumes more time because extraction and transformation take effort, but it’s effective in reaching a decision.

Take, for example, making a decision about a specific project. Extract would mean gathering all relevant data about the project—goals, tasks, estimates, and potential impacts—into one place. Transform would involve creating a brief or summary that’s digestible for others. Finally, Load could be presenting this information in a meeting or sharing it in an offline document for everyone to review. This one-time process helps in scenarios where you know exactly what you need to make an informed decision.

Gather Insights for Future Decisions with Reverse ETL

Sometimes, the decision you’re gathering insights for is still in the future, or you don’t yet need to make it. In these cases, you might have insights and data points you want to consider and save for later, even if you’re unsure what they’ll be used for or when. This is where reverse ETL becomes very useful.

You can start by extracting and transforming the data point into something digestible—perhaps a table where you log the insight, link, impact, and potential future relevance. Then, later, when you need to make a decision, you have a resource to refer back to. To demonstrate, imagine you collect customers' feedback on some unmet need over time, and once the moment comes and the company wants to kick off a new solution in that area, you already have a bunch of insights to rely on.

Enriching Data Insights with ELT

In some situations, you want to enrich data insights with additional dimensions and data points. For example, when someone opens a Jira ticket, you might want to capture details like priority, team, component, size, and related documents. However, if opening a Jira ticket requires filling out 15 different fields, it becomes time-consuming, overly complex, and ultimately less efficient.

In such cases, it might make sense to use an ELT approach. ELT stands for Extract, Load, Transform. Imagine that you only provide the title and description when opening the Jira ticket. In the description, you might mention priority and components in free-text format. A separate process then transforms this initial input into the structured fields.

Another example could be feature requests. When someone opens a feature request for your product, you don’t want to create obstacles by requiring extensive details. They can simply explain what they want. Later, the product team can transform this information by adding custom fields, assigning categories, or rephrasing the feature request in standard terms. This approach is ideal for cases where you need a more efficient, fast, and scalable way to ingest data.

Schedule Sync vs. Real-Time

One approach to gathering product insights, such as customer requests, friction points, or feature usage, is Schedule Sync. With this method, you review various insights from multiple sources on a recurring basis (e.g., weekly). You collect relevant insights and push them into a chosen destination—whether it’s a database, a document, or a spreadsheet.

The other approach is Real-Time. Whenever you encounter a data point related to the product, like a support chat, a public review, or a feature request, you immediately extract, transform, and load it into the destination.

The difference is that the Real-Time approach ensures data freshness but can compromise consistency. On the other hand, Schedule Sync offers more consistency and a reliable view of the data, though it comes with a delay before insights are available.

Choosing between these depends on the use case. Real-Time is usually preferred when the timing is critical, and you must act quickly. This is often the case with new competitors in the space, strategic feature requests, or urgent bugs.

Stay Up-to-Date with CDC

Imagine you’re tracking a major feature release and monitoring where you stand on a weekly basis. You need information on the engineering tasks, marketing campaign plan, and the design studio collateral. So, you gather the marketing tasks from Monday, you pull in Gantt charts from JIRA, and you build your own view of the project and its expected launch date.

As you review this week by week, you need to ensure that your destination—whether a slide or a spreadsheet—stays up-to-date. Instead of rechecking all tasks and repeating the entire process, you can use a Change Data Capture (CDC) approach. With CDC, you can query and extract only the items that have changed and perform ETL on those updates.

For instance, you could set up a view to show JIRA tickets updated in the last seven days or retrieve the latest updates from Monday boards. This makes keeping your destination data current much more efficient and less time-consuming.

Conclusions

As knowledge workers, much of our work involves data ingestion, manipulation, and management. Understanding the patterns and strategies used to handle data in the software world can enhance our productivity and improve our day-to-day workflows.

Introduction

As a software engineer, your work doesn't end when your code reaches production. Actually, one could say it's just the beginning. Once your code is in production, it must be maintained, addressed, improved, and always available. An "incident" is a term used in software engineering to refer to a case where code in production is unavailable, doesn't behave as it should, or adversely impacts customers.

You're probably familiar with the term "bug" in software engineering. An incident is like a bug on steroids, which needs to be addressed now. Incident management refers to the entire lifecycle from the moment you identify an incident until it's resolved and ideally won't happen again. Incident management matters because a product that constantly has incidents will impact customers and, eventually, revenue. It's unrealistic to never have incidents. It is reasonable to resolve them fast (in time to resolve metric) and do your best, so the same incident does not happen again.

This post will explore the main concepts around incident management and how we can apply them and learn from them in real-world problems.

Identifying an Incident

The first challenge is to know when an incident happens. Let's take, for example, a website that starts sending errors and doesn't load for customers. Do you know it when the first customer encounters it? Do you know when the 100th customer encounters it? Or do you find out when a customer calls the company's CEO and says their website doesn't work? That's the first challenge. You must ensure your services and products are production-ready to identify an incident correctly. Production-ready means having logs, metrics, and observability tools in place, which help you understand the system's status at any time.

The second step would be to identify what is expected and abnormal. For example, if you monitor a database's CPU usage over time, you see a percentage considered normal, 70%. And then you can say anything above 70% is potentially an incident. The third step is to define benchmarks and rules for what is actually an incident. For example, if the CPU goes above 90% on Saturday and the checkout smoke test fails, it is an incident.

It's important to know that incidents are not black and white. There is no one-size-fits-all. Incidents could have different priorities and affect other areas, so the approach to identifying and managing them should be flexible.

Triage and War Room

Once an incident is triggered, the owning engineer must triage it: What’s the priority? Who needs to be informed or involved? What’s the impact? Should the status page be updated, or should a meeting be opened? The triaging process is where these critical decisions are made.

The engineer typically starts a war room, physically or virtually, bringing in the necessary people. The company is aware of the incident, and insights are shared. Customer success may report impacted clients, support can highlight relevant tickets, and DevOps shares system performance insights. Relevant teams then join the effort.

The engineer is responsible for communicating the impact, current actions, next steps, and update timing. They also track completed and pending tasks. In short, triaging and the war room move the incident from acknowledgment to active resolution.

Managing the Incident

During the incident, it’s important to first focus on mitigation. For example, if the site doesn’t load, you might be able to get it to load in specific regions or ensure that some parts of the site are functional. After that, the goal is to fully resolve the incident and ensure no loose ends remain—all affected customers should no longer be impacted.

To achieve this, the incident owner must be empowered to access all the necessary resources. That engineer should be available if they need a specific engineer’s help. They must be granted during the incident if they require permissions they don’t usually have. It’s about ensuring they are fully empowered with the right tools to mitigate and resolve the issue.

Closing and Analyzing

An incident isn’t genuinely closed until a Root Cause Analysis (RCA) is in place. In other words, you can only consider the incident over and closed once you understand what caused it and have identified the steps needed to prevent it from happening again. As the old saying goes, "Fool me once, shame on you; fool me twice, shame on me." Preventing the following incident is not about chance or destiny. We must act on our findings and take the necessary steps to ensure it doesn’t happen again.

When closing an incident, it’s important to ensure everyone is in the loop and aware of the impact and the final resolution. If there’s an external status page, it should be updated accordingly. Finally, the RCA should include concrete action items that the team can take to prevent similar incidents in the future.

Applying It to Real-World Problems

I believe we can learn from the structured approach to incident management and apply some of its principles to the non-structured problems we might face daily. I will review three issues that each organization has likely encountered and explain how I apply certain practices from incident management to deal with them.

Deal with Employee Retention

The negotiation to retain an employee often starts when they’ve already decided to leave. Similar to how services are monitored, you should consider how to sense the 'heartbeat' of each employee to get early signals of churn risk. Examples include skip-level 1-on-1s, internal NPS or feedback surveys, and recurring sessions with an HRBP. Building processes and tools to monitor and be 'alerted' when something goes off track is crucial. For example, if a UX designer’s 1-on-1 with the VP felt disengaged, didn’t answer the NPS survey, and missed the last company all-hands meeting, it might require check-in and potentially 'trigger an incident.'

Implement a New Tool or Process

Let’s assume the team has been working with Jira, and the company has decided to switch to Monday. This type of change resembles managing an incident—a clear outcome (complete the transition), a defined timeframe (as soon as possible), and implementation is spread across the organization. It’s important to have a clear owner, such as a Program Manager, to manage this. Next, they must plan and communicate milestones, as engineers do when communicating a mitigation plan. If additional resources or permissions are needed during the process—like admin access to Jira or dedicated sessions with teams—the owner must be empowered to obtain them. Ownership and access to resources are crucial to success in these cases.

Quarterly Planning

Before planning the next quarter, we usually reflect on the previous one. However, this reflection often remains shallow. Inspired by the root cause analysis and the 'five whys,' we should dig deeper to understand why the past quarter went well (or didn’t). With clear understanding and action items, we can plan the next quarter and ensure we don’t repeat the same mistakes—or, hopefully, we repeat our successes. As with incidents, the quarter isn’t over until a deep analysis is conducted and insights are extracted to improve the next one.

Summary

I'm obsessed with productivity and efficiency; a big part is decision-making. With incident management, each decision counts, and the faster, the better. While incidents clearly impact our day-to-day, problems and dilemmas often don’t. I believe we can take inspiration from incident management—topics like on-call schedules, alerting & monitoring, war rooms, and root cause analysis—to handle non-structured problems in our day-to-day lives more efficiently and faster.

OKRs Are Dynamic

OKRs are a common framework used to manage and organize a company's tasks and projects to meet its specific goals and objectives. When defining OKRs, you can think of it as a top-to-bottom process where the company decides its objectives and key results. Then, each department feels about how they can contribute to them, and eventually, each team needs to decide on the top priority and most impactful tasks to meet those objectives.

However, in reality, OKRs are a bit more dynamic. Let's take an example where the original goal was to improve the user's time-to-value —let's say, improve onboarding to first action time by 30%. In reality, once the teams and departments start working towards this goal, they realize that they have achieved it in a way, but then retention goes down. This means they improved the onboarding dramatically, but retention took a hit. Previously, it took longer to onboard users, but those already onboarded were able to find meaningful experiences and remained engaged with the product. With the new enhancements, it's not like that anymore.

They went back to management to discuss and decide to change the KR. Now, instead of looking at onboarding time, they look at two-week retention. The interesting question is how this KR change should impact the company.

• Option #1: Wait for the next planning cycle and hope the people involved in these discussions will do what they can with the new KR.

• Option #2: Regroup and plan everything again, validating the plans and ensuring the current tasks and internal objectives meet the new KRs.

There might be a third option: take a step back and explore the world of front-end applications.

Lessons from the Virtual DOM

Imagine a webpage where you have certain elements: you have the header and the footer, and then maybe you have a catalog area, a "Purchase Now" button, and so on. The elements are structured in some hierarchy, as shown below.

Web browsers treat the webpage as a tree structure (Document Object Model, DOM). Let’s assume the active sale has a timer of two minutes, and once the sale ends, the webpage will:

1. Remove the active sale.

2. Show the next sale.

3. Refresh the product carousel.

The webpage has several alternatives:

• Option #1: Wait for the next page to refresh to load updated data.

• Option #2: Refresh the page and load the entire page from scratch.

See where I’m going with this analogy? It's a similar problem to the one we introduced earlier with our OKRs example.

Luckily, we have a third option. Let’s discuss how it decides on changes to apply to the current page.

Instead of directly manipulating the DOM (e.g., refresh the page and components), the Virtual DOM compares the current state against the desired state. Once done, it changes only the elements needed instead of the entire page. Let’s see it in action:

In the example above, the virtual DOM updates only the necessary components instead of triggering a full page refresh. This improves performance and enhances the user experience.

The page’s tree structure plays a crucial role here. When the sale ends, multiple elements need updating, and we can identify them by examining the components (nodes) under the Sale Banner, such as the title, label, and price.

Keeping OKRs Up to Date

Let’s return to our OKRs example. After the company published its OKRs, each department created its plan. Now, let’s think of the DOM. The DOM represents the OKRs, structured so that each task ties directly to its relevant key result and each key result to its objective. This creates a tree-like structure, starting from the company’s top objective down to the last task connected to it.

When changing the onboarding KR to a retention KR, we can consider this process the Virtual DOM. 

Looking at the tree structure, it’s clear that we need to revisit tasks 1 & 2. However, this doesn’t necessarily mean we will change them. For example, “Implement in-app guides” may remain relevant to the new retention KR.

We don’t need to involve the entire organization. By identifying the potentially affected areas, we can focus on discussing changes with the relevant teams. Once the updates are finalized, we publish and share the new version with everyone—just like updating a webpage after a sale ends.

Here are some tips that you can take right now to implement this:

1. Ensure every relation is in place, meaning each department's KR relates to the company's original KR. It's much easier to build it in a more structured way with tools like Notion or spreadsheets.

2. Link the day-to-day tasks—whether our personal tasks, marketing projects, or R&D features—to tie back up. It's hard; sometimes, it might be related to more than one KR, and still, we need to have a structured way to revisit it in the future.

3. Once changes occur, see them in a structured way—because you have already identified all the affected tasks and maybe KRs—and bring all the relevant people to the table to build an updated plan version.

4. Once you have an update, update the OKRs, change the tasks, revisit efficiently, and share it with the company.

Summary

Overall, we drew inspiration from how web pages manage state changes and applied that to the OKRs process. While goals and objectives are typically set once a quarter or year, finding a way to revisit them weekly and efficiently implement changes across the company as needed can be a key to success.

Intro

I once worked in a large organization that frequently restructured its teams, roles, and hierarchies to adapt to changing goals and realities—sometimes as often as once a year. Over time, it started to feel like history was repeating itself, as the lack of knowledge about past decisions frequently led to poor outcomes.

At one point, the organization had structured itself around geographical management—each site or group was overseen by someone managing multiple disciplines and roles. Later, after reflecting on various insights, management shifted to a profession-based model, where roles were managed independently to allow disciplines to grow and specialize (similar to guilds in a squads model).

Years later, they reverted to the original geographical structure for various reasons. What concerned me wasn’t the decision itself but the fact that no one seemed to remember why it hadn’t worked well the first time. Unsurprisingly, the same issues reappeared.

I believe we can learn a lot from how codebases are managed to avoid these organizational problems.

Enter Git Commit

A commit in Git represents a piece of code added to the codebase. In the diagram above, the main branch reflects the current state of the code. To reach this state, you must pass through all the changes made along the way—from A to F. This concept is similar to event sourcing.

When committing to the code, you must include your identity and explain the change. This combination allows for valuable insights, such as:

• Who last modified this line of code? (via the “blame” feature)

• Why did we add this function?

• When was this file deleted?

Additionally, Git allows you to return to a previous state of the code at any time, like reverting from point F back to point E.

Why do we need it?

Putting the technical jargon aside, consider you have a recipe for a cake. Over time, you start experimenting and improving the recipe. Maybe even other members join and update based on their own taste. Eventually, you have only the final version with zero knowledge of how it got there or that something even changed.

As computers became common and you could develop software on personal computers, the need for collaborative work increased, and source code management (SCM) was created. With it, we can work on scale, collaborate effectively, and recover quickly from incidents.

Back to the re-organization

Returning to my initial story, let’s imagine this was the case:

The ability to scale and learn from past experiments improves when historical changes and who made them are visible. Additionally, working with context is always the better option.

In reality, managing decisions for a team or a company isn’t like managing code. However, it can be done using decision logs.

Tips for effective decision logging

You can get started with your own Decision Version Control system today:

1. Create a Simple Google Sheet: Set up a Google Sheet with columns for Area, Date, Decision, and Owner to track all significant decisions.

2. Set a Review Timeline: For each decision, determine a time to revisit it (e.g., six months from now).

3. Automate Reminders: Set automated reminders for essential decisions to prompt a review at the appropriate time.

4. Conduct Retrospectives: When reviewing a past decision, ask yourself if it was right and what lessons can be drawn from it.

5. Leverage Historical Context: Review past entries in the same area before making new decisions to gain valuable context and avoid repeating mistakes.

Intro

In my previous post, I explored how to break high-level metrics into actionable working agreements, using the DORA metrics framework as a reference. Now, I’d like to extend this concept to our day-to-day practices.

Imagine our team is working on a new feature to increase product adoption, and we decided to measure success by tracking the average weekly sessions per user. What should we monitor once the feature is deployed and the rollout begins? Should we immediately focus on weekly sessions per user? Of course not.

Risk Metrics

In the example above, the primary focus is on risk metrics during most deployments. These typically include error logs, CPU utilization, overall system health, user complaints, and bugs. Within the first few hours, you’re more likely to detect if the new feature introduces any regressions than to see a noticeable impact on the defined KPI. This aligns with the broader concept of monitoring: ensuring your product remains functional and efficient and maintains its normal KPIs.

Tips for defining risk metrics

• They should be easily measurable.

• Regressions should be identifiable within minutes.

• They should impact critical product flows.

For instance, the number of login attempts is a crucial risk metric. It allows you to spot regressions quickly, and the impact on the product is significant. However, consider factors like seasonality (e.g., weekends), which can lead to false positives.

Leading and Lagging Metrics

Metrics can signal that something is about to happen (leading) or reflect something that has already occurred (lagging). It’s crucial to select the right metrics based on your goals.

At one point, I worked with a product team that spent 70% of its allocation on maintenance—addressing bugs, technical debt, and production stabilization. This was a classic lagging metric, representing an already escalated situation. To address this, I began tracking leading indicators like the throughput rate of maintenance tickets and the number of production alerts.

For example, there were weeks when we had three daily alerts, ten new tickets were opened, and we only closed four. By tracking these metrics regularly, patterns began to emerge, and addressing them eventually helped us reduce our overall maintenance allocation from 70% to 40%.

Tips for defining leading metrics

• Use methods like the KPI tree to drill down to actionable, lower-level metrics.

• Apply a root cause mindset by asking why. For example, “Why do we spend so much time on maintenance? Because we have too many tickets. Why do we have so many tickets? Because new ones keep opening before we can close the old ones.”

• Define actions based on results. For example, if the throughput rate hits a 50% threshold, we will halt new work and escalate to the group manager. If no actionable step can be tied to a metric, it’s probably not a good leading indicator.

Conclusion

Defining metrics is only the first step. The real challenge lies in tracking, monitoring, and continually improving them. It is crucial to invest more time in working with risk metrics and identifying the correct leading indicators. Focusing on these can transform minor improvements into meaningful, long-term changes impacting overall performance.

When we immerse ourselves in data points, insights, and signals as part of our work, it’s easy to get overwhelmed. Deciding what to focus on and what to ignore can be challenging. This dilemma is present in almost every role: how a Product Manager chooses the key metrics to track, how a Sales Engineer scopes and prioritizes an implementation, how a Salesperson identifies the core dilemmas, and how an Engineer pinpoints the root cause of an incident.

A Gartner survey found that knowledge workers use an average of 11 software applications (along with additional tools they may create for themselves). For example, in the case of a software incident, consider the multitude of applications, logs, and messages one needs to sift through to get to the root of the problem. Root Cause Analysis (RCA) is a methodology that involves digging deep until the actual cause of an issue is identified.

In this post, I will discuss how a KPI tree employs a similar approach—only from the other direction—to help you stay focused and improve what truly matters.

I’ll focus on the Change Lead Time metric in software development in the example below. This metric measures the time it takes to implement and deploy a piece of software to production. Improving it in isolation is nearly impossible, like trying to resolve a vague, acute incident without clarity. To tackle this, we’ll use the KPI tree technique to break it down.

First, we’ll deconstruct the metric by identifying the stages contributing to the total lead time. We’ll ask ourselves: What are the specific steps that make up the entire lead time cycle?

Change lead time is the sum of all the steps in the process. We can ask ourselves, “How can I improve the time it takes to review a PR?” This brings us closer to the root cause and a leading metric we can actually improve.

But we can go even further:

The time to reach a PR is the number of commits in a PR multiplied by the average time to commit code. This makes it specific and actionable. But we won’t stop here:

After breaking it down further, we can now focus on improving even smaller metrics, like reducing the average coding time or the time to understand requirements. The point is clear: the more we dissect the primary metric, the more actionable it becomes.

Next, we’ll work in reverse, exploring how optimizing these lower-level metrics can significantly impact the high-level objective.

The more precise the requirement, the less time it takes to understand it. To ensure clarity, I’ve added criteria for an explicit requirement, such as limiting it to one user story and including at least two examples. These working agreements are designed to influence the primary metric by improving its underlying sub-metrics.

We can continue this process with the remaining metrics and evaluate the results over time. Based on their impact, working agreements can be refined and adapted. The key takeaway is that we are now laser-focused on improving our primary metric.

Intro

In my last post, I highlighted how context improves decision-making. This time, I’ll focus on decision-making and how to proceed when context is lacking.

While context is necessary, we must avoid analysis paralysis and prioritize making decisions and taking action.

Let’s explore some software design concepts that help tackle this issue.

Lazy Loading

Do you sometimes experience a web page where more content loads as you scroll, or images start blurry and gradually sharpen? That's lazy loading in action.

The system identifies which components are essential (required context) to display immediately, while other elements can be deferred and loaded later. This approach improves performance by working with minimal context.

You can "lazy load" in life, like learning a new language. If you're planning a trip to France, you might start by learning basic phrases to get around. Later, you can pick up vocabulary related to food and shopping. You "load" new words only when needed, avoiding the overwhelm of learning everything upfront and moving forward gradually.

Circuit Breaker

Imagine a product team overwhelmed with work—top-priority projects, critical bugs, and more. As frustration builds, a key team member falls ill. Pushing the team harder won’t necessarily help. Instead, using a “circuit breaker” approach, you acknowledge the disruption and pause new requests to the team. You check in daily to monitor their status, resuming work only when they return to normal.

This pattern protects systems from crashing, improves resilience, and isolates problems. It shows how, even without full context or resources, quick decisions can still be made and more considerable setbacks prevented.

Concurrency Control

Imagine a restaurant (yes, food again!) where each time a customer orders, everyone else must wait until that order is completed before the next one can be taken. Why? This is to avoid the situation where you order something unavailable because someone else just ordered the last one.

Not very efficient, right? This approach is called Pessimistic Concurrency Control. It assumes there will be conflicts between orders, so they must be processed one at a time. In other words, you need the full context (what everyone else has ordered) to take a new order.

Alternatively, the Optimistic alternative assumes that there won't be conflicts most of the time. Here, everyone can take orders at their own pace, but when an order is submitted to the system, it might turn out that a dish you ordered is no longer available ("We're sorry, the Mediterranean Garden Delight is sold out"). This approach avoids exhaustive checks, allowing faster action even if you occasionally lack full context.

Avoid Analysis Paralysis

While seeking more context is essential, moving forward and making decisions is even more crucial. Overthinking and overanalyzing waste resources can lead to missed opportunities. Instead, try these tips:

• Clear Criteria: Define what is essential to move forward and what is merely nice to have.

• Imperfection is Perfection: Recognize that striving for perfection is unnecessary, so choose your battles wisely.

• Always End Meetings with Action Items: Set a rule that no meeting ends without clear action items. It’s better to make a decision, even if it’s wrong, than to make none.

• Iterate: All the examples above allow for mistakes, iterations, and improvements. The first attempt may not be perfect but will lead to a better solution.

Conclusion

Context is valuable in decision-making, but action is essential to avoid stagnation. Techniques like lazy loading, circuit breakers, and optimistic concurrency control in software design show how to proceed efficiently even with limited context by focusing on progress and adaptability.

Intro

A (vegan) customer walks into a restaurant (why are stories always about food?), reads the menu, and orders a salad (the "Mediterranean Garden Delight"). The cook prepares the meal, and the waiter serves it. However, the customer receives a not-so-vegan salad dressing. What went wrong?

I strongly believe in context—the more context you have (ideally in one place), the better decisions you can make. Let’s revisit the restaurant story with this in mind:

• Before entering, the customer knew the restaurant’s name, location, and perhaps some reviews.

• After entering, they saw the menu and maybe a dish or two nearby.

• The waiter knew what the customer ordered but didn’t ask about dietary restrictions.

• The cook only knew which meal to prepare and for which table.

Had the waiter asked about dietary restrictions, or if the menu clearly listed allergens, or if the customer had provided this info earlier, the experience would have been much smoother.

That said, context comes at a cost—asking for more information can slow things down, reduce conversions, and cause fatigue.

Now, let’s look at how context works in software design and share some tips for managing it.

Context

Context refers to the circumstances that form the setting for an event, statement, or idea, allowing it to be fully understood.

Here are some technical examples of context:

• Frontend application context

• AI LLM context

• Microservices bounded context

Let’s dive into each.

Frontend Context Can Change

Frontend apps have context, often called state. For example, when I log into a gaming site, the context might include my username, recently played games and scores.

In our restaurant example, the frontend is the menu. The menu was printed last week, so it may not reflect what’s actually available (e.g., the waiter might inform you of unavailable dishes).

Similarly, changing the web application context and managing state updates are crucial. We’ll touch on this more later.

Varied Context Types

In LLMs (like Claude or GPT), the context window is the maximum number of tokens (characters) that can be processed. The context can include text, files, or media. Some context is required (like the prompt), while others are optional (like the temperature setting).

In our restaurant, there's a limit to how much you can order (you likely can’t order 1,000 meals) and optional parameters (you can request a meal change, but it’s not mandatory).

Bounded Context to Simplify

In microservices, particularly in domain-driven design, bounded context allows each service to manage its own terms. For instance, a “Campaign” in the acquisition service refers to paid ads, while in the game service, it refers to a character’s journey.

Similarly, the customer uses "Order" to mean the dishes they’ve chosen, while the cook uses "Order" to refer to missing ingredients. Setting the context makes communication more evident.

Tips

To make better decisions and reduce cognitive load, use these tips for managing context:

1. Set the stage: Define the bounded context—what domain are we in, and what are the key terms?

2. Just enough: Provide enough context, but keep it concise. Explain why something matters and offer examples.

3. Multi-modal: Context isn’t just text. Use visuals, documents, and verbal explanations to clarify.

4. Stay updated: Context changes. Keep everyone updated and make sure changes are communicated clearly.

Let’s look at an example of building a budget for the new year.

• Stage: The manager shares the goal, boundaries (which budget areas we’re discussing), and standard terms (budget, cap, Opex, ROI).

• Context window: Provide access to past budget sessions, a shared file, a timeline, and FAQs.

• Variety: Use visuals, spreadsheets, office hours, and recordings.

• Updates: Send weekly emails and ensure everyone has the latest version with updates.

Though context has a cost, providing the proper context at the right time usually pays off.

State vs. Events

Are you familiar with meetings like Sprint Retrospectives, Post-Mortems, or Project Retrospectives, where you struggle to recall anything beyond the final outcome? We naturally focus on results rather than the process, on the end goal rather than the journey itself. However, the journey is significant, and to gain deeper insights and context, we need to understand the evolution.

I once led a several-month project and insisted on holding a retrospective. The first step was to create a list of events that described the project after each significant change. It looked something like this—

This approach is inspired by Event Sourcing. In a previous post, I discussed event-driven communication. In this post, I'll focus on tracking and analyzing using the event-sourcing method.

Event Sourcing

In traditional state-based systems, we decide what information to record and store in the latest state. For example, we might store the estimated project duration or the current scope at a given time.

With event sourcing, we record only events; the actual state is derived by "replaying" these events. Here’s an example from our project—

Let’s demonstrate it with another example. Imagine an e-commerce site that manages online purchases. A traditional state-based approach will look something like this:

While this provides a snapshot of the current purchase status, it lacks context about how it got there. For example, it becomes difficult if we want to refund delivery costs for orders that stayed in "Awaiting Delivery" for more than three days. This would likely require redesigning the data model and possibly migrating data (assuming it's available). Now, let’s see how event sourcing could solve this—

In this example, the purchase events are in chronological order, allowing us to replay them at any time to gain insights into their current or previous state.

Why Use It?

Event sourcing offers several benefits:

• Context: Provides insight into how the state is derived.

• Scalability: Enables the separation of writing new, unopinionated events from calculating the current state.

• Flexibility: Simplifies adapting to changes and new requirements since the state can always be derived by replaying past events.

Our Project Example

Returning to the project example, recording and reviewing events changed my perception of the project's success. Suddenly, I could see all the change management, reduced resources, and increased scope, which, in the bigger picture, reframed the project as successful. Simply looking at the start and end dates wouldn’t have provided this perspective.

How to Get Started:

1. Identify Objective Data Points: Decide on the key data points you can track, such as scope, available resources, dates, and other indisputable facts.

2. Maintain a Log: Record every change by adding a new event to the log, capturing the agreed-upon data points.

3. Define the “Projection”: Determine what you want to assess in the final state, such as project duration, the number of scope changes, or invested man-months.

4. Replay the Events: Go through the events chronologically and calculate the “projection” to analyze the project's evolution.

While this approach can be tedious and resource-intensive, it provides valuable context and data-driven insights that outweigh opinions. Objective data points offer a more reliable assessment than the subjective analysis of one individual.

More Use Cases

Here are some other areas where a similar approach can be applied:

• Decision-Making: Log each step and opinion from ideation to the final decision. This helps provide context and insights into why decisions were made, making revisiting and questioning confident choices easier.

• Conflict Resolution: Track the events from the beginning of the conflict. Record who was involved, what each person said, and the actions taken. Agreeing on the facts and events leading up to the conflict brings you 80% closer to resolving it.

• Career Growth Tracking: Knowing where you are now is more accessible than understanding how you got here. Tracking changes and decisions in your career allows you to be more candid and honest with yourself. Knowing your journey so far can help you better craft the road ahead.

Summary

Event sourcing is an architectural design pattern that manages the state through an event log. It offers benefits like richer history, improved context, and the ability to "time travel." This technique can also be applied to project management and career growth tracking to gain more objective insights into how things evolved.

Will you give it a try?