Six questions I've had to answer.
Open one for the short answer
I'm Ivan Silva, a senior product manager at Full Fabric, building complex B2B SaaS products. I work where enterprise customer needs meet technical complexity: APIs, integrations, workflow automation and the tools people rely on to operate software. Each question below is a piece of that work, asked the way it first reached me.
01
When a sync fails, who finds out?
Why it was hard
An enterprise customer's CRM and Full Fabric had to agree on more than the existing integration carried. And when a record failed to synchronize, staff had no easy way to see what had happened.
My part
Customer discovery, the requirements, and the interface where failures show up.
What shipped
More synchronized records, custom field and entity mapping, consent data, and a sync-management screen that shows conflicts and failures.
02
One admissions system, several application schemes. One integration?
Why it was hard
Universities received applications through an external admissions system and re-entered them by hand. The application schemes differed, and so did the authentication.
My part
I led the product specification, sequenced development with engineering, and managed acceptance.
What shipped
An integration that ends the re-entry, extended so different admissions routes run inside one shared product instance. Both related releases went out ahead of their planned dates.
03
What do you do when one record here is several records there?
Why it was hard
Academic data had to stay in step between Full Fabric and a learning platform whose data model did not match. One entity on our side could be several on theirs.
My part
I defined the data mappings and synchronization rules, worked on data protection, investigated unexpected account creation, and coordinated the fixes.
What shipped
Released, and in use across several institutions. Some extensions went out ahead of schedule. Others were delayed.
04
Many small requests or one large project: who gets the engineers?
Why it was hard
Enterprise customers raised many smaller requests, operational problems and usability concerns. They competed with larger commercial projects for the same engineers.
My part
I organized intake, kept a prioritized list, spotted the recurring issues, turned feedback into specifications, and ran the release cycles.
What shipped
Two improvement cycles that addressed customer-reported problems affecting several institutions.
05
Why was I copying requests between two tools by hand?
Why it was hard
Customer-facing requests lived in Asana. Engineering work lived in Linear. Moving information between them by hand meant duplicate effort and extra coordination.
My part
I built an automation using GitHub Actions to transfer customer requests from Asana into Linear.
What shipped
It connected customer-facing operations with engineering without requiring manual issue creation.
06
What should an AI draft, and what should a person approve?
Why it was hard
Product work repeats: requirements documents, engineering issues, release notes, changelogs, help articles. AI can draft all of them. The question is where a person has to stay.
My part
I built internal tools that turn project context into structured PRDs, engineering issues, changelogs and Help Center drafts.
What shipped
One workflow separates preparing a communication from approving its publication. A person releases it.
How I tend to answer
Find the problem behind the requested feature.
Enterprise customers describe needs as features. The request is where discovery starts.
Bring engineering in before the commitment.
Feasibility and the cheaper alternative are easier to hear before a date exists.
Build what the next customer can use too.
Bespoke is quicker to quote. Reusable is cheaper to own. I size both before choosing.
Keep a person on the approve button.
Automation drafts. Somebody accountable publishes.
About
I started in technical support and QA, wrote frontend code, co-founded a small web studio, then moved into product management. I still write code when it settles a question faster than a meeting.
More about meQuestions I am still working on
Can software remember why a decision was made?
A local cognitive engine that turns meetings, documents and messages into an evolving model of people, projects, decisions and commitments, keeping the source behind every fact and how it changed over time. Built to run offline on an iPhone. In development: the first milestone, the on-device Context Compiler, is under way.
What will next month cost, given what I decide today?
A private financial companion that predicts the month ahead, prepares for upcoming expenses and compares a decision before you make it, without needing the cloud. In product discovery.