Sana·Product design·2026
Designed the product a venture studio and its portfolio companies run on.
- Role
- Product designer,
0-1 - Team
- One PD, One PE,
One Dev - Timeline
- About 3 months to
a stable first version - Company
- Shifu Ventures
~7 companies
run daily on it, 3 weeks from first release to daily use
Asana + Attio
both subscriptions canceled, studio moved onto Sana
6 modules
all live within three months, built by a team of 3.
The context
Shifu Ventures is a venture studio that helps its portfolio companies grow their revenue and co-executes with them, across finance, marketing, product, sales, GTM, etc.
These portfolio companies provide services to each other and outside clients as well. The teams are lean, so effective resource allocation becomes very important.
So a person's week is split across several companies at once. Someone from a finance company can be working for three of them in the same week, and for that they have to plan effectively.
Before Sana, there was no one place to see any of it. A few problems came:
- 01
Goals sat in Notion for some people, in a spreadsheet for others, and nowhere at all for some. Getting visibility meant asking people to prepare a report which took days.
- 02
A task given in Slack was buried within the hour. People wrote the rest in their own notebooks. It was hard to see how people are placed without asking them, thus it impacted planning.
- 03
A meeting was scheduled in one place, its agenda written in another, and the tasks from it created in a third. Notifications were spread the same way, so seeing what needed attention meant opening three or four products and clearing each one.
The team had already tried obvious answers and dropped them.
Reason, it felt like an extra step. They were already busy, and opening another app to write down a task was not worth it when a notebook was right there.
So the answer was never another tool for another kind of work. We wanted one ecosystem where people from different companies could work together on goals, meetings, tasks and everything around them.
What the job actually was
There was no research phase. The founders had run the studio for over 2.5 years and done plenty of trial and error. They knew the problems better than any round of interviews would have told me.
The product was decided together. The founders said what they wanted from each module. The product engineer and I worked on the strategy, and I owned delivering the experience end to end.
Instead of research, I looked at how other products solved the same problems, worked through the approach with AI, and brought a written spec into every meeting.
Three constraints shaped every decision after that:
- 01
People were already struggling with the old stack. We could not ask them to wait a month or two, so we shipped something every week and let them use it early.
- 02
These were people who had picked up tools before and put them down. If Sana felt like extra work, the same thing would happen again.
- 03
Me, a product engineer, and a developer, alongside everything else the studio needed that month.
Introducing Sana
One place where the companies in the Shifu ecosystem work with each other, and where everyone has visibility on how it is going.
Sana has six modules.
- 01Tasks. Everything a person has to do, across every company.
- 02Goals. What each company is working toward, and how it is tracking.
- 03Meetings. The agenda, the discussion, and the work that comes out of it.
- 04Pipeline. The people and companies the ecosystem knows, and how strong each connection is.
- 05Inbox. Everything that needs your attention, in one queue.
- 06Wins. What people got done each week, shared with the team.
Designing straight into code
Every screen in Sana was designed straight into the codebase. I raised PRs that engineering reviewed and merged.
I had never worked this way before. I picked up Git quickly, and from there the handovers were quick and working with the devs got much faster.
It beat the old way by a distance. No building every screen by hand, no handing off a file and waiting for someone to rebuild it in code.
Experimenting cost almost nothing. Build a layout, put it in front of the team, drop it and try another the same day.
Something shipped every week. Sometimes, around ten small releases went out in a week.
Speed like that does not come from working faster. Four things made it possible:
SITUATION
A single module holds far more than one screen. The task page alone has more than a dozen states: no tasks yet, a few tasks, a list long enough to scroll, and many more. All the other modules have their own set.
A written spec lists them. Everyone reading it still has to picture them in their head.
WHAT I DID
I built every state as a live page, with each state on its own tab. Real interactive screens. Nobody has to imagine anything.
HOW IT HELPED
The handoff got much faster. The engineer had nothing left to guess at. Every state was already there to look at, so he was not stopping to ask what happens when a list is empty or a table runs long.
We went through them together, and checked each one before anything got built.
Impact
Nothing got left out, and a module went from design to shipped in about a week.
SITUATION
The inbox carries notifications from all six modules, and each one produces plenty. Each notification has different importance. A meeting starting in two hours is worth telling someone about. Someone reacting to a win is not.
So I had to work out which notifications should exist, and how important each one is.
STRUCTURE FIRST
Before the list, I designed what a notification looks like. The project it belongs to, then the item it is about, then who did what and when, so people can scan the inbox quickly.
Then the list
I gave AI my codebase and some reference material so it knew how the product was built and how good notifications read. Then I asked for every notification each module could send, and every state it could be in.
It came back with far more than I would have written. Cutting from a long list takes minutes. Realizing something is missing means going back and building it.
WHAT I DIDN'T LET AI DO
What stays and what goes was ours. The product engineer and I went through the list and cut every unimportant notification that would fill up the inbox for no reason.
The same spec was also what I put in front of the team.
IMPACT
The whole inbox took about two days, from the first brainstorm to live in production. That covered writing the spec, feedback from the founders, going through it with the product engineer, and the build itself.
SITUATION
At first I worked in the full codebase, and AI kept going out of the front end. It would write API calls, reach into the database, or add keys on its own.
The codebase was heavy and everything ran slower. I spent my time fixing code bugs instead of designing. Better prompts did not fix it.
WHAT WE DID
- We forked the production codebase into a separate copy for design work.
- Everything a designer never touches was stripped out.
- Mock data replaced the database, so I could work freely.
- Hooks blocked AI from writing outside the design files.
- And the code came out shaped like the rest of the product.
Impact
I could move fast without watching what it was doing. Less cost of experimentation.
And the handoff stayed clean. I was only handing over frontend files, so my work never conflicted with what devs were building.
SITUATION
Most of the modules do not depend on each other. A UI fix in the inbox, a new feature in meetings, and a redesign in pipeline can all be worked on in the same afternoon. Doing them one after another means not leveraging AI properly.
WHAT I DID
I used Git worktrees to run three separate sessions at once, one per module. While one was building, I was reviewing the second and writing instructions for the third. Then back to the first.
When each one was ready, I merged them into the main branch and raised the pull request.
IMPACT
Three things moved forward in the time one used to take. It made the biggest difference on small fixes and UI changes, where the work is quick but there is a lot of it.
Design decisions
Problem
Work gets decided in the meeting, as each agenda point is discussed. But assigning it meant switching to another app mid-meeting, or writing everything down and doing it later. It is one of the reasons a standalone task app never stayed.
Observation
I sat in these meetings long before Sana. The pattern was always the same. The agenda is prepared ahead, opened during the call, and checked off one by one. Tasks get handed out as each point closes, said out loud or dropped in Slack. The agenda is what decides when a task gets created, so the two belong on the same screen.
Solution
Agenda on the left, next steps on the right, and each side scrolls on its own. You can be deep into the agenda and still assign a task against the point on screen. By the time the meeting ends, the work is already sitting where they will look for it.
Impact
The team stopped keeping agendas in a separate document. People now open the meeting page during the meeting, and the follow-up work stopped going missing.
context
The studio had a rule of keeping an agenda in every meeting. Sana had to make writing it easy, and give people a way to ask for it when the host forgot.
Problem
Both sides could turn into spam. A host might write the agenda in multiple sittings, and attendees do not need telling each time. And all attendees nudging one host is the same mess pointed the other way.
Solution
Saving and telling people are separate. The agenda saves as the host writes, and nothing goes out until they press "Notify members".
The nudge follows the same idea. Everyone can see who has already nudged, and the button rests for an hour after each one.
If people already work a certain way, the product should fit around that. Cross-company tasks landing in the list people already use is one of the examples.
Setting a yearly goal and breaking it into quarters is something people do once a quarter at most. It also needs attention and thought, because everything below it follows from what gets written there.
So we intentionally kept the form long. Making it quicker would have cost us build time and given nothing back.
Where I struggled
What went wrong
Every second or third page came out slightly off from the ones before it. Spacing, a component that looks different, uneven sizes.
What I tried
Context in the prompt, existing components as reference, screenshots of the pages it had to sit beside. Didn't help much.
Why I did not build a design system
The product was changing every week. Anything built that early would have been a waste of time and effort.
What I did instead
Fixed it by hand. A lot of times, I stopped and fixed them manually, one by one. It worked, and it took days I would rather have spent building other things.
WHAT's the fix?
That is the problem I am working on now. An agent that checks new work against the design language in the codebase. It fixes the obvious things itself, uneven spacing, overlapping elements, a component that does not match. Only what needs a real decision comes to me. Still a work in progress.
What changed
- 01Tasks are actually used now.
- 02Goals became the place decisions get made. The leaders of every company open it in their important meetings. One founder told me those meetings stopped drifting and started landing on decisions.
- 03All meetings happen here. Agenda before, work handed out during, tasks in people's lists by the end.
- 04Proper visibility across workspaces: One can check how someone is placed before adding to their load.
- 05Sana became the shared brain for the whole ecosystem. Wins is still a new habit, and people are getting used to it.
What I'd change now
- 01I'd build the consistency agent while I was still designing. I saw the drift by the third module and kept fixing it by hand for weeks.
- 02I would design the habit before shipping the feature. Wins asked people to do something new, and it is the only module people are not using much.
Credits
- 01Sri and Prateek knew the problems from 2.5 years of trial and error, and backed building this one in-house.
- 02Saurabh was the product engineer. He wrote the guardrails with me, and reviewed and merged everything I raised. He was actively invovled in building Product Strategy.
- 03The teams across the portfolio used Sana while it was still WIP, and told me what was wrong every week.
