Product management · Gainesville, Florida

I write the requirements,
and I read the pull request.

Product manager with an engineering foundation. I spent two years shipping production backend, payments and mobile features, then moved to product, where I now own discovery, requirements and go to market.

Most recently at Tvisha Technologies, defining two new modules for Troop Messenger, a secure collaboration platform deployed on premise and in air gapped environments for government, defence and regulated enterprise customers. MS Computer Science candidate at the University of Florida.

See the work → s.balachendil@ufl.edu LinkedIn
6 → 4
Steps removed from the core user task
+15%
30 day retention, 5,000 customers, from A/B testing
15+
Discovery interviews that overturned my own thesis
180+
Partner targets qualified across three regions
Case studies

Four problems, and what I actually decided

Each of these includes the trade off I made, because the decision is the part worth reading. Where something did not ship, I say so.

Tvisha Technologies Product Management Intern 2026 Specified, handed to engineering

Knowledge Management for a secure collaboration platform

A requirements document specified a personalised knowledge home. After walking the real user journey I argued the front door was wrong, and reduced the core task from six steps to four.

The core screen. Search invoked by shortcut over the case she is already in. The result is the answering paragraph, not a list of titles, so most questions never require opening the article. The freshness band and owner sit under every result, so she judges trust before she reads. The second result is flagged stale rather than hidden.

The situation

Troop Messenger sells into government, defence and regulated enterprise. A knowledge module was scoped with a 40 plus requirement specification, including a personalised knowledge home as the primary entry point.

My job was to turn that specification into something buildable, and to pressure test it before engineering committed.

What I did

  • Mapped the real workflow of a caseworker at a social security office, answering a claimant question mid appointment with nine people waiting
  • Produced 26 annotated wireframes covering the full requirement inventory, mapped to six distinct user personas
  • Ran competitive analysis across 12 commercial and open source products
  • Specified retrieval, permission filtering, freshness scoring and an append only audit trail

The call I had to argue for

A landing page assumes the user came to the knowledge base. In reality they are already inside something else, and an answer is blocking them.

Counting the steps made the case. Entering through a knowledge home cost six steps and forced the caseworker to leave the case she was working in. Invoking search over her existing work cost four, and she never left. I kept the home screen, but demoted it from the front door to a workspace landing for the people whose job is knowledge itself, roughly five percent of sessions.

The argument, in one screen

Home first
The knowledge base is a place you go to
1Leave the case she is working on
2Open the knowledge module
3Find the search box
4Scan a list of result titles
5Open an article, find the section
6Navigate back and re-orient
6 stepsShe left the task
Context first
The knowledge base comes to her
1Press the shortcut, case stays on screen
2Type the question as she would say it
3Read the answering paragraph in the result
4Insert into the case note, or close
4 stepsShe never left

Two steps does not sound like much. At a counter handling forty cases a day it is the difference between an officer who checks and an officer who guesses, and a knowledge base that is accurate but unread.

The trade off

I recommended adding a thin read acknowledgement slice to version one, which the compliance story needed, and paying for it by deferring the public help centre to a later release.

Both were wanted. Only one was load bearing for the customers we were actually selling to.

Where I said no to AI

I specified that automatic answer suggestion default to disabled in secure deployments, and that stale content carry a warning the user cannot dismiss rather than being hidden.

For a caseworker with someone waiting, a fast wrong answer is worse than a slow one. The system had to surface uncertainty, not mask it.

Outcome

6 → 4
Steps in the core task
26
Wireframes, 6 personas
40+
Requirements mapped
$28K
Estimated annual displacement per 500 seats, from a competitor end of life window I identified

Status: specification and wireframes delivered and presented to leadership. Build had not begun when my internship ended, so there is no post launch metric here, and I would rather say that than imply one.

Artifacts Context first wireframes, 26 screens Requirements analysis Market and competitor deck User journey, dual perspective Benefits document by user type
Tvisha Technologies Product Management Intern 2026 Working MVP built and demonstrated

Jointly Code, a collaborative development workspace

Troop Messenger had a basic in call code editor. I scoped it into a real product, then built the prototype myself so the concept could be judged on a demo rather than a document.

The interaction, animated. Denise types on line 20 while Priya holds line 16. Conflict free replicated data types mean there is no central lock and no merge dialog, which matters because the whole system runs inside the customer's network with no external service. The status bar is the part reviewers asked about most: it shows the session is live and where the code went. Animated illustration of the interaction, reconstructed from the working build.
-->

The situation

Customers deploy on premise and often air gapped. Any collaborative editing feature had to work with no external services, and every dependency had to survive a licence review.

What I did

  • Wrote the functional specification, user stories and acceptance criteria
  • Ran a build versus buy evaluation across eight open source components
  • Built an 18 screen clickable prototype, then a working MVP in Node.js and WebSocket using a CRDT for conflict free concurrent editing
  • Wrote a run guide for a non technical stakeholder so the demo did not need me in the room

The call I had to argue for

Open core is not open source, and on premise customers find that out at the worst possible moment.

Several obvious candidates were open core: the free edition is genuinely open, but the features an enterprise actually needs sit behind a proprietary licence. In an air gapped deployment where the customer may require the whole source, that is a commitment you cannot walk back. I rejected them in favour of fully open alternatives, which cost us some polish and removed a category of risk.

The trade off

Building the MVP myself cost roughly a week of my own time. It bought a same week demo instead of a full engineering sprint spent on a concept nobody had validated.

An estimated three to four developer weeks of speculative build avoided, and a decision made on something people could actually use.

Engineering detail I am proud of

I found and fixed a data loss defect where debounced writes were cancelled rather than forced on flush, so the most recent edits could vanish on shutdown. Verified with a two client end to end sync test.

The kind of bug that only shows up under a specific shutdown sequence, and the kind you have to reason about rather than observe.

Outcome

18
Prototype screens
8
Components evaluated on licence and deployment
3 to 4
Developer weeks of speculative build avoided, estimated
2 clients
Live sync verified end to end
Artifacts Functional specification Component selection analysis Clickable prototype, 18 screens Working MVP Non technical run guide
Tvisha Technologies Go to market 2026 Pipeline delivered

Building an international channel partner pipeline

I got the targeting wrong at the start. What I did next is the reason this case study is here.

The situation

Tvisha needed resellers and distributors who could sell a secure collaboration platform into government and defence buyers. I was asked to build the pipeline from a standing start.

What went wrong

My VP of Sales reviewed the first lists and found a pattern I had missed. A significant share of my targets ran partner programmes designed to recruit us as a reseller of their products, which is the reverse of what the business needed.

What I did about it

Deleting the wrong names would have fixed the list. It would not have fixed the process that produced it.

I worked out why those companies had passed my filter, then built a three question test applied to every target before it entered the pipeline: does this company earn revenue reselling other vendors' products, does it have a vendor route rather than a reseller sign up page, and would our product fill a real gap in its catalogue. I later added a corporate status check as well, which caught several targets that had been acquired or folded into groups we had already contacted.

Outcome

180+
Qualified targets
9
Structured batches
3
Regions: North America, EMEA, APAC
3
Question qualification test, applied before entry

I also produced the outreach sequences, a partner facing question and answer sheet, and a progress report for leadership that was candid about what was not working.

Artifacts Qualification framework Partner pipeline, 9 batches Outreach sequences Progress report to leadership
NexSetu Founder, solo 2026 Thesis retired after discovery

NexSetu, a product I stopped building

I set out to fix hiring in the skilled trades. Fifteen practitioner interviews overturned my thesis three times, and a journeyman lineman delivered the fourth correction by explaining that the problem I was solving had already been solved without software.

The discovery record, kept as a decision log. Each thesis is struck through by the evidence that killed it and the person who supplied it. Three of the four corrections came from practitioners I had cold contacted, and two arrived after I published a claim publicly and was told I had it wrong.

The situation

The skilled trades are described everywhere as short of electricians. I assumed the bottleneck was supply and matching, and that a better platform would help.

I had never worked in the trade. So before scaling anything I went and asked the people who had.

What I did

  • Ran 15+ discovery interviews with contractor principals, association executives, recruiters and journeymen, including a 49 minute recorded session with an IBEW business manager
  • Worked both sides of an industry that largely does not talk to itself, union and merit shop
  • Mapped the existing credentialing landscape across NCCER, DOL registered apprenticeship, RAPIDS and state licensure to establish what was already portable
  • Built the platform end to end as sole engineer: FastAPI and async SQLAlchemy backend, React 19 and TypeScript frontend, 63 passing backend tests

The call I had to argue for, with myself

There is no shortage of applicants. Contractors are sitting on stacks of resumes they do not trust.

Four recruiters told me independently that the strongest electricians are not applying to anything. A workforce development director put it more plainly: there are plenty of people. That killed the premise. The binding constraint was employer trust, not candidate supply, which meant the AI matching engine I had planned would have optimised the wrong side of the market entirely. I retired it and shipped deterministic matching instead, scoring certification overlap, distance, pay alignment and availability, where every result can be explained to the contractor relying on it.

The trade off

I eliminated four candidate product directions against consumer reporting law, labor law and fair chance hiring norms before any engineering commitment.

One would have surfaced the employers a candidate had left off their resume. It would have worked. It would also have landed hardest on people with criminal records, who this trade deliberately hires and deliberately does not interrogate about gaps. I did not build it.

What I got wrong, and who corrected me

I published that everything up to the point a worker is certified is recorded and everything after is invisible. A journeyman lineman told me that was wrong, and he was right.

It is not invisible. It is not written down. Reputation moves by phone call between people who already know each other, and he fields those calls most days.

Where it stands

The correction went further than I expected. I had the network stopping at the state line: it does not, because you can always call where a man came from. I had storm and travel work as the place it breaks down: travel is what builds the connections. And I had assumed a worker with no history was at a disadvantage, when in fact his reputation starts on day one of the job.

That last point mattered most. The harm I had spent two months designing around, a formal record that quietly penalises anyone without one, is not a problem this trade currently has. I would have introduced it.

Status: no users, no revenue, thesis retired. What I have instead is an evidenced account of how hiring trust actually works in this trade, and a habit of finding out before building rather than after.

Artifacts Discovery record, 15+ interviews Credentialing landscape map Ruled out directions, with reasons Code · FastAPI, React 19, TypeScript, 63 tests ↗
How I work

Six things I keep coming back to

Not values. Rules I have actually applied, each one with a decision behind it.

01

Count the steps before arguing the design

"This flow feels wrong" loses the argument. "This costs six steps and one context switch, the alternative costs four and none" wins it. Numbers turn a taste debate into a decision.

02

Build the thing before asking anyone to fund it

A working demo settles in five minutes what a specification argues about for two weeks. If I can build a rough version myself, that is usually cheaper than the meeting.

03

Decide where the product should refuse to be confident

Every system has cases where the honest answer is uncertainty. Designing that in, rather than hiding it, is what separates a tool people trust from one they route around.

04

Fix the process, not just the output

When my partner targeting was wrong, correcting the list would have taken an afternoon. Working out why the list was wrong took longer and stopped it recurring.

05

Go and ask before you build

Fifteen interviews reversed my own thesis three times and cost me nothing but time. The same corrections arriving after launch would have cost a year. Being wrong early is the cheapest thing available to a product manager.

06

Decide what never enters the backlog

Prioritising inside a backlog is the easy half. I have killed four product directions on legal and ethical grounds before a line of code was written, and that has saved more than any ordering decision I have made.

Engineering background

Two years shipping production systems

The foundation underneath the product work. At Bunderbrains, a startup building a chat based commerce platform for local businesses competing with quick commerce incumbents.

Payments
Bunderbrains
Integrated the PhonePe gateway over REST APIs, scaling transaction volume 40% at a 99.8% success rate. A payment webview cut two seconds out of checkout, which on a chat based commerce flow is the difference between a customer finishing and abandoning.
Backend performance
Bunderbrains
Optimised microservices architecture in Python, FastAPI and MySQL, reducing P95 API latency by 40% through query tuning and service decomposition. The slowest requests were the ones merchants hit while a customer was waiting on them, so the tail was the part that mattered.
Growth and experimentation
Bunderbrains
Ran A/B tests and instrumented analytics in Redash, improving 30 day retention by 15% across 5,000 customers. Led cross functional merchant growth work with marketing and operations, scaling active merchants 30%.
Real time delivery
Bunderbrains
Built messaging over Firebase push and SMS sustaining 50,000 plus monthly notifications, and architected a migration framework enabling a full NodeJS to Python service migration.
Distributed systems
University of Florida
Reddit style platform in Gleam OTP using actor based concurrency, sustaining 100,000 simulated users at 5,000 requests per second under 200ms. Parallelised breadth first search achieving 4.2x speedup on graphs of 100,000 plus nodes.

Currently looking for summer 2027

Product management and technical product roles, particularly in developer tools, infrastructure, security and B2B software sold to technical buyers.

Email me LinkedIn GitHub Resume, PDF