Certified Scrum Product Owner® (CSPO®)
Scrum Alliance
Issued April 2021 · Credential ID 1368704
Toufiq Kazi
AI Product Management · Product Thinking
I started by understanding what needed to be built. Now I’m asking what is worth building.
I am a Business Analyst with 8+ years of experience working closely with users, stakeholders and delivery teams.
I am expanding that experience toward Product Management, exploring how AI can support better decisions, reduce meaningful effort and improve the way people work.
01 / 8+ Years
In Business Analysis
02 / CSPO®
Certified
03 / AI Products
Product exploration & building
04 / Pune, India
Based in India
01
Who I Am
For the first part of my career, my work was about understanding what needed to be built.
As a Business Analyst, I worked closely with users, stakeholders and delivery teams to understand business needs and turn them into products that could actually be built.
Over time, my questions started moving further upstream. I became less focused only on what needed to be built and more interested in how the problem was framed, what was actually worth solving, and what the product should deliberately leave out.
I’m exploring that next part of the journey through Product Management and AI. Building is how I test what I think I know, and each product gives me a better question to work on next.
02
Credentials
Two credentialsAI First Product Management Fellowship
Product Space
Issued August 2026 · Credential ID PSPM281099
03
How I Think
Five questionsThe way I approach a product starts before the solution.
- 01
What problem are we actually solving?
I try to understand the problem before discussing the solution. That means looking beyond the stated requirement, understanding who is affected, what is making the problem difficult, and whether it is actually worth solving.
- 02
What is worth building?
Not every problem needs a large product. I look for the smallest intervention that can meaningfully change the outcome, then make deliberate choices about what belongs outside the product.
- 03
Where does AI genuinely help?
I’m interested in AI when it improves a decision, reduces meaningful effort, or changes what a product can do. The technology is not the starting point. The problem is.
- 04
What should the product deliberately not do?
Every product has boundaries. Deciding what not to build is often as important as deciding what to build. Constraints make the product clearer and the trade-offs easier to understand.
- 05
What did I learn from building it?
I treat each product as a way to test what I think I know. The outcome is not always a successful solution. Sometimes the more useful result is a better question, a clearer trade-off, or an assumption I no longer believe.
04
What I've Built
Two case studies01AI Travel Intelligence
Routo
Helping people spend less time searching and more time deciding.
The problem
Travel planning has become an information problem disguised as a decision problem.
People can find hundreds of destinations, reviews, videos and recommendations, yet still struggle to decide where they should actually go.
The problem was not a lack of information. It was knowing what to do with all of it.
The shift
I initially thought the opportunity was to build a better travel planning platform.
The more I explored the problem, the more I realised that another discovery platform would only add to the choice.
The product needed to help with the decision itself.
That became the question behind Routo:
Will this help someone make a better travel decision?
The product
Routo is an AI travel intelligence platform built around decision-making.
Instead of presenting users with more destinations to compare, it considers their travel goals, preferences, budget and constraints to recommend the option that best fits their situation.
The recommendation is only part of the experience. Routo also explains why it fits, makes the important trade-offs visible, and keeps the final decision with the user.
The decisions
- 01
Solve the decision, not the discovery
Most travel products give people more choices.
Routo deliberately does the opposite. The goal is not to help someone discover more destinations. It is to help them confidently choose one.
- 02
Let AI guide, not decide
A recommendation is easier to trust when the reasoning is visible.
Routo was designed to explain why a destination fits, what the user gives up, and where the recommendation may be weaker. AI provides the reasoning, but the decision remains with the user.
- 03
Build context before recommending
Good recommendations start with understanding the user.
Instead of asking for a long list of preferences upfront, Routo builds context through the interaction. The product can then use that context to make the recommendation more relevant without turning the experience into a form.
- 04
Protect simplicity
Every new feature had to justify the effort it introduced.
The question was simple:
Does this reduce the effort required to make a decision?
If it did not, it stayed out of the MVP.
What I learned
Routo changed how I think about building AI products.
It reinforced that the AI layer is only one part of the product. The quality of the underlying data, the structure of the decision, the way uncertainty is communicated, and the trade-offs exposed to the user all affect whether the experience is useful.
It also showed me that AI product design is a balance between consistency and flexibility. More freedom can make AI feel natural, but more structure can make decisions more reliable.
The biggest lesson was simpler: AI cannot compensate for an unclear product decision.
02
AI Customer Support Automation
Designing a support system where AI handles the repetitive work and people handle the decisions that matter.
The problem
Customer support involves a lot of repetitive operational work.
A request comes in. Someone classifies it, decides how urgent it is, routes it to the right team, acknowledges the customer, and tracks what happens next.
The opportunity was not simply to generate faster replies. It was to improve the process around the conversation.
How much of that work could AI handle, and where should a person still make the decision?
The shift
At first, I was thinking about support as a conversation between a customer and an agent.
As I mapped the workflow, the bigger problem became clearer. A support request moves through several decisions before it is resolved: what is it about, how urgent is it, who should handle it, can it be resolved automatically, and when does a person need to step in?
That changed how I thought about the product.
The goal was not to automate the conversation. It was to improve the support process around it.
AI could handle the repetitive classification and routing work, while people could stay responsible for cases that required investigation, judgment, or intervention.
The product
The product is an AI-enabled support operating model that connects customer intake, triage, routing, resolution and closure.
A customer request enters through Gmail. AI interprets the request and classifies it by category, sentiment and priority. Business rules then determine how it should be handled and which team should receive it.
From there, the workflow can continue through an AI-assisted resolution path or escalate to a support team through Slack when human intervention is required.
The ticket remains tracked throughout the process, with the final resolution captured before the customer is notified.
- 1
Customer request
Intake through Gmail - 2
AI triage
Category · Sentiment · Priority - 3
Business rules
Routing · SLA · Exceptions - 4
Support path
AI resolution / Human escalation - 5
Ticket state
One record, tracked throughout - 6
Customer communication
Resolution captured, then notified
Product decisions
- 01
Use AI for triage, not just response generation
The first useful role for AI was not writing an answer. It was understanding the incoming request well enough to determine what should happen next.
- 02
Keep business rules outside the model
Classification alone does not determine the outcome. Rules such as refund precedence, priority and team routing shape what happens next. Those decisions need to remain explicit and predictable.
- 03
Keep humans in the loop
Not every support case should be automated.
The product became more useful when the boundary was explicit: let automation handle repeatable work, and bring people in when investigation or judgment is required.
- 04
Treat the ticket as shared state
The customer, support team and automation need to refer to the same ticket throughout its lifecycle. Testing exposed a ticket ID mismatch, which made state consistency a product concern rather than simply a technical detail.
- 05
Stop at the right scope
There was always more that could be automated.
The project deliberately stopped at the core support lifecycle instead of expanding into every possible workflow.
Knowing when not to add another layer was part of designing the product.
What I learned
- 01
Automation is not the product
Building the workflow made one thing clear: the automation layer is only the mechanism.
The product is the support process created around it.
- 02
AI classification only matters when it drives an action
Category, sentiment and priority are useful because they change what happens next.
Classification without a downstream decision is just another piece of information.
- 03
Automation needs a boundary
The useful question was not whether a case could be automated. It was whether automation was appropriate for that case.
That distinction helped define where the system should stop and human judgment should begin.
- 04
Testing changed the product thinking
The architecture looked right on paper. Testing revealed something it did not.
A ticket ID mismatch meant that the ticket created, acknowledged and resolved were not consistently referring to the same underlying record.
It was a small defect with a larger lesson: state consistency is part of the customer experience.
A support system can have the right AI, the right workflow and the right integrations. If the pieces do not agree about what is happening, trust breaks down.
- 05
Scope is a product decision
There was always more that could be automated. The project deliberately stopped at the core support lifecycle.
That constraint kept the product focused and made the boundary of the system easier to reason about.
Closing
The project changed the question I ask about AI automation.
Instead of asking how much of a process can be automated, I now think more about where automation creates value, where rules need to remain explicit, and where human judgment should take over.
05
Why I Build
I started my career close to the work of understanding business needs, users and what needed to be built.
Over time, I became more interested in the questions that come before requirements: what problem are we solving, who are we solving it for, and what should the product actually do?
Building gives me a way to explore those questions rather than answering them only in theory.
What I Believe
Technology rarely solves a problem on its own.
The harder work usually happens earlier: understanding the problem, making the right trade-offs, and deciding what not to build.
I believe good product decisions come from curiosity, evidence and iteration, not from having the right answer at the beginning.
What I’m Building Towards
I’m building toward becoming an AI Product Manager who can work across problem discovery, product strategy, AI and execution.
The products on this site are part of that process.
Each one gives me a chance to test an idea, make a decision, learn something, and carry that learning into the next problem.
Every product should leave me with a better question than the one I started with.