Author: admin

  • From Prompts to Agents: Level-Up an AI Workflow

    Let me cut to the chase: today I’m zooming in on conversational AI, mostly the LLMs. Those models that speak, write, and “think” alongside us. Why? Because this space is moving faster than most product teams, and it’s suddenly relevant to anyone who types into an AI chatbox… or wants their workflow to run without them.

    What’s the Real Gap: Great Prompt vs. Manual Agent

    I’ve built a lot of prompts. Maybe you have too a template for user stories, competitor benchmarking, release checklists. But I’m no stranger to agents either. Here’s the gist:

    A rich, reusable prompt is like a supercharged search query. I run it, get my result, tweak it, and maybe save for another day.
    A manual agent? This is next-level: I hit “Run,” and it does a bunch of stuff for me… decisions, context, maybe several steps in a row. Sometimes, it even tells me what’s next.

    Here’s how I see it:

    • Every prompt needs me :/ every time, start to finish.
    • An agent remembers why it exists. It’s got decision trees, action lists, context carryover.
    • Prompts answer questions. Agents actually do stuff.

    How Do I Turn My Epic Prompt Into a Manual Agent?

    Some days, my prompts feel so advanced it’s a shame not to call them agents. So I made the upgrade, and you can too. Here’s my go-to checklist for this transition:

    1. I clarify my agent’s goal. Not just “answer this,” but “do this, in this way, so I don’t have to micromanage.”
    2. I restructure the prompt to include context, instructions, inputs, and possible next actions.
    3. I add logic. If X, then do Y (like “if negative feedback, escalate to user research”).
    4. I let it remember stuff…context, previous answers, anything useful.
    5. I teach it how to format and deliver results (like, “output table for Jira” or “send summary to Slack”).
    6. I connect it to a manual trigger: button is goood enough for the beggining. Forget about API and webhook… for now 🙂
    7. I run tests, fix bugs, repeat until smooth enough

    Manual triggering means I’m still in control. But after that? My agent runs a show, not just answers a question.

    The Critique: It’s NOT Just About More Prompts

    Most guides focus on better prompts, bigger libraries, smoother templates. But honestly, that misses a few elephants in the room:

    • Not all AI skills live inside prompt engineering. Ethics, validation, project management… this all matter.
    • Work with agents and LLMs is rarely linear. Sometimes I jump from prompt to agent, sometimes zigzag according to project needs.
    • Teams need versioning, sharing, actual process. A prompt library doesn’t cut it if I want repeatable business results.
    • New models keep popping up. Prompt skills must evolve with them.

    Lessons I Stick To:

    • Prompting is where I start, Agents is where I scale.
    • Sometimes, a killer prompt is enough. Sometimes an agent saves me hours.
    • Choice depends on my process, not on the “ultimate AI workflow.”
    • Testing, context, and iterating win every time.

    Final Thoughts

    Looking back, what moved the needle for me wasn’t just writing more advanced prompts. It was building mini-systems that gave me leverage, saved my time, and made AI a background player instead of an inbox. Agents aren’t for everyone or every scenario. But if you want to level-up, they’re worth the leap.

    If you need some mentoring – feel free to hit me.
    For you its free. For teams its not 🙂

  • Small Automations > One Big One. n8n for Product Managers

    I was recently working on a process map that was supposed to be automated by one big workflow. The project was meant to be transformative – one solid automation that would move everything. Two months later it was in a drawer. It was too complicated, it broke with every change to our processes, and on top of that, nobody understood it.

    That’s classic waterfall thinking, but in the world of automation. And today I want to flip that idea on its head.

    A Lesson from Product

    You know how PMs talk about MVPs and iterations? “Instead of one big feature, build something small and check for feedback”. The same works for automation. Instead of trying to automate your entire product discovery flow with one workhorse – build ten small, independent ones.

    Take collecting customer feedback. It would be easy to think: “I’ll build one powerful automation that collects feedback, analyzes sentiment, categorizes it, sends it to Google Sheets, posts to Slack, and generates a summary for the report”.

    But what happens? If something goes wrong at the sentiment stage – the whole flow breaks. If you change the category structure – you need to rewrite the logic. If OpenAI goes down – nothing gets through.

    Instead: ten separate, small, independent automations, each doing one thing – but doing it well.

    How This Looks in n8n

    I recently analyzed the most frequently used workflows on this platform by product managers. And you know what? Everyone who says “it works” operates on exactly this principle.

    First automation: feedback lands in Google Sheets. Period.
    Second: every new row in Sheets triggers sentiment analysis.
    Third: sends a Slack notification if sentiment is negative.
    Fourth: weekly, gathers all feedback and sends it to Notion.

    Each workflow is 5-10 nodes. Easy to build. Easy to fix. Easy to understand.

    And you know what’s the best part? You can work asynchronously. Feedback appears in Sheets a minute after it arrives? No problem. Sentiment doesn’t get analyzed right away? Nothing breaks, because it’s a separate automation.

    Specifically: What to Automate for a PM

    If you’re working on product discovery, a few small things are worth your attention:

    Monitoring Product Hunt – a small workflow that checks every hour what’s new. Sends to Slack. That’s it. This automation takes 15 minutes to put together.

    Collecting feature requests – form arrives, request goes to Google Sheets. And that’s all. A separate automation categorizes them. Yet another one, separate, aggregates them weekly and sends the report.

    Tracking competitors – one workflow takes screenshots of competitor pages every Friday. A second workflow compares them to the previous week and sends differences to Notion. Two separate processes.

    Analyzing sales calls – one automation extracts transcripts. Another analyzes them. A third tags insights. Each does one thing – but does it well.

    The Philosophy of Small Pieces

    There’s something deeper here. Sometimes I hear PMs say: “but this will be scattered”. Well, of course it will. And that’s a feature, not a bug.

    Scattered systems are:

    • Easier to debug (something broke? One thing, not ten)
    • Easier to scale (want to add a new category? You modify one workflow, not the entire structure)
    • Easier to understand (new team member looks at a diagram with 5 nodes, not 50)
    • More resilient (if YouTube API breaks, your competitor analysis doesn’t suffer much, because it’s a separate thing)

    This is a principle that engineers know as microservices. But we PMs don’t usually think about it when working with automation.

    The Problem with Big Plans

    There’s always someone who says: “But if everything is scattered, it’ll be a mess”. Of course, if you don’t organize it. But that’s not a problem with small automations. That’s a problem with documentation and process.

    Two files:

    1. Google Doc with a list of all workflows (what it does, when it triggers, who maintains it)
    2. Tag in n8n: product-discoverymonitoringanalysisreporting

    Done. Now you have transparency.

    When to Start

    Don’t wait for the “perfect automation”. Build a workflow for collecting feedback today. It’ll take 30 minutes. Tomorrow add a second one for analysis. In a week you’ll have a system that actually works, instead of one hybrid monolith sitting on the shelf.

    Will it be imperfect? Yes. Will it be scattered? Yes. Will it work? Also yes.

    And that’s what matters for a product manager – things that work, that you can change without apocalypse, and that actually save time in discovery work.

    Instead of one big dream about automation, take ten small wins.

  • AI in Product Management:Q3 2025 quick Rundown

    The last few months have really shaken things up.

    Seriously, did any product manager expect this pace of change? Many probably struggled to keep up (myself included). What happened…? Long story short: a lot, fast, and sometimes a bit chaotic.

    Enter GPT-5: The New Star

    OpenAI announced GPT-5 as the best model in the world. Ever seen a model decide by itself when to answer instantly or when to take its time? Now you have it. No need to ask twice. GPT-5 makes decisions for us, and get this – everyone gets access. No paywall. Your competitor, your buddy, your LinkedIn connection -they’ve got it too. Ever wondered why everyone suddenly talks automation?

    Sometimes it slows down, other times it answers instantly. Mini and nano versions are out there. Few hallucinations (still happens, let’s not kid ourselves). Safety tests? Thousands of hours.

    Gemini 2.0/2.5 – The Agent Era

    Google’s not sitting idle. Gemini 2.0/2.5 moves towards “agents” – systems that don’t just answer, they do stuff for you. Actually, they do. “Gemini for Home” understands what your camera shows, not just “motion detected.” I had a weird case recently – a noise and the AI said, “Courier dropped off a package, left.” Strange, useful. PMs, time to change your mindset – UX and data architecture are changing. It’s no longer text interaction, but background agents doing their thing.

    Claude 4 and a Million Tokens of Context

    Anyone in research noticed Claude 4? A million tokens of context (not a thousand, or ten thousand, a million). Throw everything at it – customer feedback, competitor analysis, docs. Claude handles it. Deliverables last too – generate a report, send it to Slack, check back next week, still there.

    AI Hallucinations – A Real Threat

    One big topic: hallucinations. AI can make stuff up confidently. Regulated industries (fintech, medtech) – one mistake means lost trust. Compliance nightmare. A user burned once might never come back. PMs must watch production outputs, craft smart prompts (not as easy as it sounds), and critically evaluate results – don’t blindly trust the model.

    AI-Powered PM Tools Are Booming

    The PM tool race with AI is heating up: Jira AI, Productboard AI, Notion AI (imagine PRDs without it?), Aha! AI. Automated feature prioritization, workflow automation, predictive task assignment = faster and smoother. But hey! 75% of PMs already use AI tools, so if it’s not you, someone else is ahead. Don’t say I didn’t warn you.

    Agentic AI. The Future of Product Discovery

    Agentic AI is about to change the game. Not chatbots, but agents who decide, act, gather data, and recommend – deliver results, not just answers. Product discovery? Instead of searching “triathlon bike,” the agent collects data, shows options, advises. Real personalization, real-time insight.

    What Does This All Mean?

    A few simple facts:

    • AI speeds up everything. Time to rethink infrastructure and processes; two weeks is the new three months.
    • Hallucinations exist and will. Monitor and fix.
    • Agents are real and here. UX changes, tools evolve.
    • Context is currency. Don’t miss out.
    • Access is universal. You win not by the tool but how skillfully you use it.
  • Everything’s a Gamble: Validating Your Backlog with Experiments

    Introduction

    Validating product ideas through experimentation is a crucial practice in product management. Rather than making assumptions about what users want, product managers must treat everything in the backlog as a hypothesis that needs to be tested.

    The lean startup methodology emphasizes the importance of getting out of the building and testing your ideas with real users. As Steve Blank says, “No facts exist inside the building, only opinions.” Rather than developing products based on hunches and internal discussions, we need to verify our assumptions by running experiments that involve target users.

    This validation mindset is key because we often think we understand our users, but we can be wrong in our assumptions about their problems, needs, and behaviors. Running quick experiments allows us to collect real data on how users respond to potential solutions. This reduces risk and ensures we build products that effectively serve user needs.

    Validating ideas through experimentation is not just about avoiding failure – it helps companies pivot faster and identify winning products sooner. By testing product concepts early and often, we can focus energy on the ideas that have the most potential to delight users and achieve business goals.

    Everything in the Backlog is a Hypothesis

    Product managers often make the mistake of treating everything in their backlog as facts and certainties, rather than assumptions and hypotheses that need validation. The truth is, every new product idea, every feature on your roadmap represents a hypothesis about what will bring value to users. You believe that building that feature will drive business outcomes like increased engagement, retention or revenue. But until you test that assumption with real users, it remains just that – an unproven hypothesis.

    Approaching your backlog with the mindset that “everything is a bet” is immensely powerful. It forces you to question your assumptions and prevents you from wasting time building features users don’t want. The core principle is that you should test your hypotheses early and often through experiments, not build out your roadmap based on hunches. Prototyping and releasing minimum viable versions allows you to validate what resonates with users, so you can double down on what delivers results. With an experimentation mindset, you turn ideas into facts.

    Validating Through Experimentation

    Every product hypothesis needs validation through experimentation. Rather than guessing what users want, product managers should design and run experiments to test assumptions.

    There are several types of experiments that can validate hypotheses:

    • Prototype testing: Create a prototype of a feature or product and get feedback from target users. This can range from low-fidelity sketches to clickable prototypes. Observe how users interact with it and incorporate feedback into the next iteration.
    • Landing page tests: Build a landing page describing the product and drive traffic to it from target customer segments. Measure conversion rates, clickthroughs, signups, etc. to gauge interest.
    • A/B testing: Release variant versions of a product or feature to subsets of users. Analyze the usage data to identify which variant better achieves the desired metric.
    • Email/ad campaigns: Run focused email campaigns or online ads for the product concept and track engagement. Are people clicking through or signing up?
    • Exploratory user research: Interview or survey potential users about the product concept. Gauge their enthusiasm, understand pain points, and clarify the target market.
    • Beta tests: Release an early product version to a limited set of users. Collect feedback, monitor usage metrics, and gain insights to improve the product before a full launch.

    The key is to identify your biggest assumptions and focus experimentation efforts on validating those product hypotheses first. Using data to make decisions builds confidence in product direction and improves the chances of success.

    Determining Key Metrics

    Choosing the right metrics to measure experiments is critical for understanding if a feature or change had the intended impact. Rather than relying on vanity metrics like clicks or downloads, focus on metrics tied to core business or user goals.

    For example, if the experiment involves a new sign up flow, measure metrics like sign up conversion rate, drop off at each step, and quality of new users. If testing a new recommendation algorithm, measure metrics like engagement, clicks/orders per user, and revenue per user.

    Ideally, have a small set of quantitative metrics that map to overall objectives. Be specific in defining each metric and how it will be calculated prior to running tests. Avoid vanity metrics that seem positive but don’t actually indicate performance. Track metrics over both the short and long-term to account for changes over time.

    Set clear hypotheses and target metric thresholds for each experiment. For example, aim to increase conversion rate from landing page by 10% or get 5% more users to regularly engage with new feature. This helps interpret results and identify meaningful vs. statistical changes.

    Prioritizing Experiments

    When it comes to experimentation, you can’t test everything at once. You’ll need to prioritize which hypotheses to validate first. Focus your experiments on the biggest risks and assumptions in your product roadmap.

    For example, if you’re planning a major new feature but aren’t sure how customers will respond, test demand for that feature before fully building it out. Or if you’re redesigning your signup flow, test the new flow against the old one before rolling it out completely.

    Prioritize experiments that have the potential to make the biggest impact. Look for assumptions that, if proven wrong, would significantly influence your roadmap and strategy. Test those risky hypotheses first to avoid wasted effort and build confidence as you move forward.

    Some key areas to focus experiment prioritization:

    • New features with high dev investment
    • Significant changes to core flows
    • Redesigns of critical pages
    • Major marketing and go-to-market initiatives
    • Pricing changes or new business models

    By validating the biggest assumptions early, you can refine your roadmap, focus engineering capacity on proven solutions, and avoid costly false directions. Move fast by testing your biggest risks before you build.

    Running Effective Experiments

    When running experiments, it’s important to follow best practices to get valid, reliable results. Here are some tips:

    • Have a clear hypothesis. What do you think will happen and why? Spell out your assumptions. This focuses the experiment and helps interpret results.
    • Isolate variables. Change only one factor at a time so you know what caused the effect. If you change multiple things, you won’t know which impacted the outcome.
    • Use A/B testing. Split your audience into two groups – the control gets the current version, the experiment gets the change. This isolates the variable.
    • Choose relevant metrics. Pick metrics that will validate or invalidate your hypothesis. Focus on the key outcomes that matter.
    • Run enough iterations. Test until statistical significance is reached. For web experiments, often hundreds or thousands of users are needed.
    • Randomize users. Assign users randomly to groups to avoid sampling bias. Randomization ensures fairness.
    • Analyze results correctly. Use statistics, not gut feelings. Beware of things like novelty effects wearing off.
    • Learn and improve. No experiment is a complete failure if you learn something. Iteratively improve based on insights gained.

    Following structured best practices for setting up and analyzing experiments makes it more likely you’ll get valid results and actionable insights. With the right approach, experiments can inform smart product development.

    Analyzing and Learning

    Once an experiment is complete, it’s critical to thoroughly analyze the results and extract key learnings. This is the most important part of the process.

    Evaluate whether your hypothesis was proven or disproven based on the metrics you defined upfront. Dig into the data and try to understand why users responded the way they did. Look for any surprising or unexpected results.

    Some key questions to ask:

    • Did we observe the desired behavior change in our target segment? Why or why not?
    • How did the key metrics we defined compare to our hypothesis?
    • Are there differences we should analyze by segment, cohort, or attribute?
    • What user feedback or qualitative data did we gather from the experiment?
    • What worked well that we should amplify going forward?
    • What didn’t work that we should revise or remove?

    The learnings from each experiment build on top of each other, so make sure to document the results thoroughly. Look for patterns and insights that apply more broadly beyond the specific experiment. Track key learnings over time to continuously improve.

    Be sure to share results across your team and organization. Experiments are wasted if the lessons don’t lead to changes in strategy, priorities, and execution.

    Iterating Quickly

    A crucial advantage of validating hypotheses through experiments is the ability to learn and iterate quickly. Each experiment provides an opportunity to gain insights into what resonates with users and what doesn’t. As you run experiments, pay close attention to the results and feedback. Look for patterns and key learnings that can inform future iterations.

    Resist the urge to theorize and make assumptions. Instead, let the data guide you. If a hypothesis is invalidated, use that learning to update your thinking. If an experiment shows positive results, double down and expand on what’s working. Small tweaks and adjustments add up over time.

    Move fast, leverage learnings, and continually refine based on real user data. The faster you iterate, the quicker you hone in on product solutions users want. Be nimble and flexible, evolving the product as you go. Don’t get stuck on a predetermined path, be open to pivot based on new insights. Iterating quickly allows you to stay aligned with user needs even as they change over time.

    The key is to establish a rapid cycle of ideation, experimentation, learning and iteration. By implementing this build-measure-learn loop, you can iterate your way to product-market fit faster than the competition. Speed matters when it comes to innovation, so focus on quick experiments that drive continuous improvement. The faster you iterate, the faster you win.

    Avoiding Common Mistakes

    Conducting experiments effectively requires avoiding some common pitfalls that can undermine results:

    • Confirmation bias – Looking only for data that confirms your hypothesis, and ignoring contradictory data. Remain objective and acknowledge all results.
    • Small sample sizes – Testing with too few users leads to variability and inaccurate conclusions. Determine minimum sample sizes upfront for statistical significance.
    • Changing multiple variables – Altering more than one thing at once makes it impossible to know which change impacted the metrics. Isolate each variable and test them independently.
    • No control group – Having a baseline to compare against is crucial. Run A/B tests or keep part of your product unchanged as a control.
    • Stopping too soon – Ending an experiment prematurely before collecting enough data can miss long term effects or trends. Run tests long enough to achieve stastical confidence.
    • No actionable metrics – Focusing on vanity metrics that don’t directly measure outcomes. Define quantifiable, meaningful metrics aligned to key goals.
    • Not testing repeatedly – One-off tests in artificial environments provide limited value. Build a culture of continuous experimentation.

    Proactively avoiding these missteps will lead to higher quality results from experiments to validate product hypotheses. Failing fast to proven learning is the desired outcome.

    Conclusion

    Taking an experimental approach to product development is critical for product managers. Rather than assuming that every idea and feature will be successful, product managers should view their backlogs as a series of hypotheses that need validation.

    By designing and running experiments, product managers can test key assumptions and gain valuable insights into what resonates with users. This enables more informed product decisions, reducing waste and increasing the chances of shipping something customers truly want.

    A validation mindset also encourages rapid iteration. Failures become learning opportunities rather than setbacks, as experiments reveal areas for improvement. Product managers can quickly pivot based on user feedback, optimizing the product experience over time.

    In today’s competitive landscape, winning products come from validating ideas early and often. Product managers who embrace experimentation are better equipped to identify and double down on what delivers real value. While experimentation takes work, the payoff is immense. Validated learning leads to customer-informed products that solve real problems and satisfy market needs.

    By treating everything as a testable hypothesis, product managers can focus their efforts on creating products users love. And they can avoid wasted time and resources building features no one wants. Experimentation transforms product discovery from guesswork to a scientific, evidence-based process. For any product manager seeking innovation and growth, it is an indispensable approach.