Veena Studio

Product management in a founder's office, on a DAW that became an agent

Role: Product Manager, Founder's Office. Remote, with a company registered in Delaware. Four interface design screens from this work are published.

Two things need saying before section 01, because a reader deserves to know the epistemic status of what follows.

First, the company is real and independently verifiable. Veena Studio Inc. ships a live product at veena.studio, with an application at daw.veena.studio, a free tier and a $20 per month paid tier. That is checkable by anyone.

Second, my dates are not currently reliable, and I am not going to guess at them. My own public pages give two incompatible ranges for this role. Until I can state a corrected start and end month with confidence, this case study omits dates entirely rather than picking the more flattering version. The work described is real. The calendar is pending correction.

Third, no outcome metrics appear here. Earlier write-ups of this project on my site claimed a 35% latency reduction, 1,200-plus waitlist signups in thirty days, a 28% lift in seven-day retention and forty-plus musician interviews. I cannot evidence any of those figures and they are absent from this document. Section 13 explains that properly.

---

01 · Context

A founder's office role is not a product management role with a different title. It is a different job.

A conventional PM owns a surface, a squad and a roadmap for that surface. A founder's office PM owns whatever the founder cannot get to this week, which changes, and the actual skill is triage rather than depth. In a small company shipping a technically ambitious product, that means the work is genuinely broad: roadmap and sprint mechanics one week, positioning and launch copy the next, interface specification the week after.

The product itself makes this harder in an interesting way. Veena Studio is a browser-based digital audio workstation, and browser DAWs occupy a category where users have exceptionally precise, exceptionally unforgiving expectations set by desktop software that has had twenty-five years to get good. A producer comparing anything to Ableton Live or Logic Pro is not comparing feature lists. They are comparing feel.

And over the period this work covers, the product's centre of gravity moved. The earlier framing was a performance problem: get professional audio into a browser without the latency and clumsiness that had made every previous attempt feel like a toy. The product as it exists today leads with something different. It leads with an agent. The headline is "Meet your personal music producer" and the pitch is an AI CoProducer that builds a track layer by layer, with stem separation, MIDI generation, text-to-audio, voice-to-instrument and smart mixing.

That shift, from make the browser fast enough to make the software do the producing, is the most interesting thing about this case study, and it is a shift I can describe honestly because it is visible in the artifacts. What I cannot claim is authorship of the strategy behind it.

02 · Problem

Stated as the product's problem, not mine.

Browser DAWs had a credibility problem earned over a decade. Latency, unresponsive timelines, interfaces that looked like web apps rather than instruments. A professional producer's default assumption about a browser DAW is that it is a demo.

Collaboration was the only thing the browser was clearly better at, and it was not enough. Native DAWs are single-machine, file-based, and collaboration means sending large files and hoping plugin versions match. The web solves this structurally. But nobody switches for collaboration if the core experience degrades, because the core experience is the work.

The underlying platform constraint is real. Audio work in a browser fights a single-threaded main thread, garbage collection pauses that land as audible glitches, and a rendering model designed for documents rather than sixty-frames-per-second meters. These are not implementation failures, they are properties of the platform that have to be engineered around.

And then a strategic problem arrived on top of the technical one. Generative audio models got good enough, fast enough, that the question stopped being "can a browser host a DAW" and became "what is a DAW for, when a model can produce a passable arrangement from a sentence". That reframes the product entirely. A tool that helps you execute is a different business from a tool that produces on your behalf.

03 · Why the problem mattered

Because the addressable market shape changes with the answer. A high-fidelity browser DAW competes for existing producers, which is a hard, small, loyal market. An agentic music tool competes for people who want music and cannot produce it, which is enormous and has almost no loyalty to existing workflows. Those are different companies with different pricing, different acquisition and different definitions of success.

Because trust in creative tools is asymmetric and unforgiving. A producer who loses one session to a crash does not file a bug, they leave, and they tell other producers. Reliability is not a quality attribute in this category, it is the licence to operate.

Because AI in a creative tool has a legitimacy problem that a payments product does not. Musicians have well-founded objections to generative audio, concerning training data, attribution and the displacement of session work. The live product's own FAQ includes "Isn't AI in art bad?", which tells you the company knows this is the first question. Any product decision about AI in this category is also a positioning decision about the company's relationship to musicians, and pretending otherwise is how creative tools lose their audience.

04 · Research

I need to be exact here.

Product-market-fit research with musicians was part of this role: conversations with people who make music, spanning bedroom producers through to people working in studios, plus workflow analysis of the incumbent desktop tools.

I am not going to state a number of interviews. My earlier write-ups said forty-plus. I do not have an interview log, a recruitment record or a consent trail that supports a count, and a count without a log is decoration. The activity happened. The figure is not evidenced, so it is gone.

What the workflow analysis consisted of. Sitting with how Ableton Live and Logic Pro are actually operated, which is mostly keyboard. Producers do not navigate a DAW with a mouse, they navigate it with shortcuts they stopped consciously thinking about years ago. A DAW that requires pointing is a DAW that requires relearning, and relearning is the real switching cost, not price and not features.

What I did not do. No quantitative survey. No instrumented latency benchmarking that I can produce. No usability study with a recruited panel and a protocol. Where the earlier case study implied a measurement regime, it was overstating a set of conversations and observations.

05 · Insights

Cloud collaboration is wanted and will not be traded for feel. Producers were consistent about this. Real-time collaboration is desirable. It is not desirable enough to accept anything that feels slower than native. The conclusion is uncomfortable: collaboration cannot be the wedge. It has to be a bonus on top of a core experience that already stands alone.

Keyboard shortcuts are the navigation model, not an accelerator for power users. This is the single most actionable insight from the research and the one most likely to be got wrong by a team building on the web, where shortcuts are conventionally an enhancement. In a DAW they are the interface. A web app that captures a key combination the DAW needs has broken the product.

Metering has to feel alive. Level meters that stutter make the entire application feel cheap, and the judgement is instant and pre-rational. A producer does not think "this is dropping frames", they think "this is not serious software". Perceived performance in this category is largely carried by a few small continuously-animating elements.

Density reads as professional. Consumer software reduces options to reduce anxiety. Professional audio software presents a lot at once, because the user's mental model is already dense and hiding things means hunting for them. Progressive disclosure, which is usually good practice, is actively wrong on a mixer.

And the insight the product itself eventually acted on: the constraint for most people is not tooling, it is ability. Every improvement to a DAW's precision helps someone who already knows what they want to do. That is a minority of people who want to make music. An agent that produces a first draft changes who the product is for. Whether that is the right business is a strategy question. That it is a different business is not in doubt.

06 · Product thinking

The founder's office version of product thinking is mostly about deciding which of several defensible directions gets this quarter, and the honest framing of this period is that there were two live theories about the product.

Theory one: win on fidelity. Be the browser DAW that a professional cannot dismiss. Engineer around the platform's constraints, match desktop density, earn credibility with the people who set taste in the category, and let collaboration be the reason they stay. Small market, high loyalty, defensible on craft.

Theory two: win on capability. Put a model in the middle of the product and let it do the parts the user cannot. Large market, low loyalty, defensible on model access and product surface rather than on craft.

These theories disagree about almost everything downstream. Fidelity says spend the next six engineer-months on the audio graph and the timeline. Capability says spend them on agent orchestration, credit accounting and inference cost. Fidelity prices per seat to professionals. Capability prices on usage, which is exactly what the live product does at $20 a month with a credit allowance.

The live product resolved toward capability. It leads with the CoProducer, it prices on credits, and its free tier is limited by requests per day rather than by features. That is a coherent, committed answer.

My contribution to that resolution is not something I should overstate. In a founder's office, strategy of that magnitude is the founder's. What a PM in that seat does is make each theory concrete enough to be chosen between: what would have to be true, what it costs, what it forecloses, what the first release looks like. Writing the options honestly, including the one you personally find less interesting, is most of the job.

07 · Strategy

The decisions I can describe as decisions, with their reasoning.

Own the roadmap mechanics so the founder does not have to. Sprint planning, backlog prioritisation, user stories with acceptance criteria, release coordination. This is unglamorous and it is the actual deliverable of the role. A founder's throughput is the company's throughput, and the measurable output of a founder's office PM is how much decision-making stops needing the founder.

Write acceptance criteria for audio features as behavioural, not functional. "Stem separation returns four tracks" is a functional criterion and it is nearly useless. "A user who imports a track and requests stems can begin editing the vocal within N seconds, and the transport does not stall while separation runs" is a behavioural criterion and it constrains the implementation in the way that matters. In audio, the timing of a feature is the feature.

Treat the plugin and collaboration surfaces as ecosystem questions, not feature questions. A marketplace is a two-sided problem. Writing user stories for a marketplace before there is demand on either side is a way of feeling productive, and I would now push much harder to defer that work.

Position against the AI objection directly rather than around it. The live product's FAQ asks "Isn't AI in art bad?" in the company's own voice. Naming the objection in your own marketing is the right call. It converts a suspicion the visitor already has into a conversation you are hosting.

Price the free tier on requests, not features. Five CoProducer requests a day is a better free tier than a feature-crippled one, because it lets a user see the whole product and hit a wall of appetite rather than a wall of permission. This is the live product's approach and I think it is correct.

08 · Information architecture

A DAW's information architecture is unusual because it is spatial and persistent rather than navigational. The user does not move between pages, they inhabit one surface for hours.

Session                        the durable object; everything is inside it
  Transport                    global, always visible, never more than one
  Timeline / Arrangement       horizontal time, vertical tracks
    Track                      audio or MIDI, with its own chain
      Clip                     the editable unit
      Chain                    effects, in order
  Mixer                        the same tracks, viewed as levels
  Library                      samples, presets, generated material
  Agent                        the CoProducer, acting on all of the above

Two structural observations that took the longest to get right.

Timeline and mixer are two views of one object, and the user must never doubt it. A change in one appears instantly in the other. The moment a user suspects they are looking at two representations that can disagree, they start verifying, and verifying costs the whole session's flow.

The agent is architecturally awkward and the awkwardness is the interesting part. Every other element in that tree owns a region of the screen. The agent acts across all of them. It can add a track, alter a clip, change a chain, generate library content. So where does it live? A panel implies it is a tool among tools, which understates it. Ambient presence everywhere implies it is always intervening, which producers will hate. The live product's framing, layer by layer and one step at a time, is a resolution of this: the agent is a sequence of proposals rather than a continuous presence, which keeps the user's hands on the object. This problem is general to AI-native products and I have written about it separately in this archive.

09 · UX and design

Four Veena interface screens are published in the gallery and cover brand identity and UI system work for the product.

Hierarchy. Time is the primary axis and everything else defers to it. The transport is global and singular. The timeline dominates. Track headers are dense but subordinate. The mixer is a peer view rather than a page. Nothing competes with the horizontal reading of time.

Interaction cost. Measured in a unit specific to this category: how many actions between hearing something wrong and having changed it. That loop, notice then locate then adjust then re-listen, is the fundamental cycle of production, and every millisecond and every click inside it is felt hundreds of times a session. Features that improve the product elsewhere but add a step inside that loop are net negative.

Cognitive load. Deliberately high, and this is the right choice. Sweller's work on cognitive load is about load extraneous to the task; for a producer, the density of a mixer is intrinsic to the task and hiding it creates the worse burden of remembering where things went. What must be reduced is load that is not about the music: ambiguous state, unlabelled controls, undiscoverable shortcuts.

Visual system. Dark, as the category expects, and for a real reason: producers work long sessions in dimmed rooms and a bright interface is physically tiring. Sub-pixel precision on the timeline, because a producer aligning transients is reading pixels and a half-pixel offset reads as a misalignment in the audio. Colour reserved for state and for track identity, never decoration.

Perceived performance, which is most of this product's design problem. The 0.1 second threshold from Card, Robertson and Mackinlay's response-time work, restated by Nielsen, is the boundary at which an interaction feels like direct manipulation of an object rather than a request to a system. A DAW has to sit under it for every gesture on the timeline. Where the work genuinely takes longer, stem separation, generation, rendering, the design has to be explicit about it: show the operation as an operation, keep the rest of the session live, never freeze the transport. The failure mode is not slowness, it is ambiguity about whether the application is still there.

Trust. In a creative tool, trust means the user believes their work is safe. Autosave that is visible. Undo that is total, including undo of anything the agent did. Destructive operations that are never one gesture away. An agent that proposes rather than applies. The single most important design rule for an agent inside a creative tool: the user's work must never be modified in a way they cannot instantly and completely reverse.

Error and empty states. An empty session is the hardest screen in a creative tool, because the user's problem at that moment is not ignorance of the interface, it is not knowing what to make. This is where an agent has an unusually strong answer, and it may be the best argument for the capability strategy in section 06: the blank page is the actual churn point, and a CoProducer that offers a first layer addresses it directly.

Accessibility, stated honestly. Professional audio software is largely inaccessible, and a browser DAW inherits both the opportunity and the failure. The web platform gives real affordances here that native audio software has never had. I did not deliver accessibility work in this role and cannot claim it. Naming it as an open gap is more useful than a paragraph implying otherwise.

Tradeoffs. Density over simplicity, correct for producers and a barrier for beginners, which is precisely the tension the agent strategy resolves. Dark over light, ergonomically right and a legibility cost in bright rooms. Keyboard-first over discoverable, right for the target user and hostile to first-timers.

10 · Technology

Two eras, and I will be precise about which claims attach to which.

The technology the earlier case study described was Web Audio API with WebAssembly for the audio engine, React for the interface with custom event emitters bypassing React state for audio-critical updates, and Web Workers to keep the main thread free. The stated blocker was that React's render cycle is too slow for audio-rate UI updates. That is a real and well-understood problem: React's reconciliation is designed for correctness at document speed, and a level meter at sixty frames per second driven through component state will cause dropped frames and garbage collection pressure. Bypassing the framework for a narrow, high-frequency path is the standard and correct answer.

I did not write that engine. I am a product manager and I want to be exact about the line: I can explain why the architecture is shaped this way, I specified behaviour that constrained it, and I did not implement it.

The technology the live product now demonstrates is a different centre of gravity. Stem separation, MIDI generation, text-to-audio, voice-to-instrument and audio-to-MIDI conversion are model inference workloads. They are not real-time and they cannot be. That means the architecture now has to hold two contradictory regimes at once: a real-time path measured in milliseconds where the audio graph lives, and an inference path measured in seconds where the models live. Everything hard about the current product is at the seam between them.

The credit system in the pricing, 20,000 credits on the paid tier, is the commercial expression of that seam. Real-time audio processing is a fixed cost that scales with users. Inference is a variable cost that scales with usage. A product spanning both cannot price on seats alone, which is why the metering exists.

What I will not claim. No latency figure. The 35% reduction that appears in my earlier write-ups has no benchmark, no harness and no before-and-after artifact behind it that I can produce, and it also appears elsewhere on my own site attached to a completely different metric, which is its own warning. It is not repeated here.

11 · Marketing and GTM

ICP, and it moved. The fidelity theory targets working producers and serious hobbyists. The capability theory targets people who want to make music and lack the skill or patience to operate a DAW. The live product's messaging, "Meet your personal music producer", is unambiguously aimed at the second group.

Positioning. Not "a DAW in your browser", which invites a comparison it loses. Instead an agentic collaborator, which is a category where the incumbents have no answer. That is the right axis of competition: pick the dimension where twenty-five years of accumulated desktop advantage is irrelevant.

Messaging that does real work. "Bring in any track, get real editable stems, and finish music you own." Every clause defuses an objection. Any track means no lock-in. Real editable stems means it is not a toy generator. Music you own addresses the rights anxiety that is the single largest barrier to a musician trying an AI tool. That last clause is the most important four words in the product's copy.

Channel. Community-led, centred on Discord, with presence across X, Instagram, TikTok and YouTube. This is correct for music production, which has always been a demonstration culture. Producers learn from watching other producers work. A tool whose output is inherently shareable and whose process is inherently watchable should be distributed by showing, not by explaining.

Free tier as the acquisition mechanic. Five requests a day. Enough to experience the loop, not enough to finish a project.

Content surfaces. The company runs features, tools, guides, a blog, comparison pages and an agentic-DAW explainer, which is a conventional and sensible search strategy for a category with high-intent comparison queries.

What I can evidence about my own GTM contribution: not much. Go-to-market work was part of the role. The specific outcomes I previously published, 1,200-plus waitlist signups in thirty days and a 28% retention improvement, are not evidenced and are excluded. I can describe the reasoning and the structure of the work. I cannot show you the results.

12 · Execution

What the role covered:

• Roadmap ownership: sprint planning, backlog prioritisation, release coordination
• User stories and acceptance criteria for DAW features, including collaboration and plugin-marketplace surfaces
• Product-market-fit research with musicians, and workflow analysis of incumbent desktop DAWs
• Interface specification and design contribution; four screens published covering brand identity and the UI system
• Go-to-market structure and positioning work
• Product health reporting to the founder

What exists as a public artifact from this work: four interface design screens.

What exists as a company artifact, independent of my role: the live product, its pricing, its feature set and its content surfaces.

13 · Results

No outcome metrics are reported for this role, because none can be evidenced.

Removed from this case study, and listed here so the omission is deliberate and traceable rather than quiet:

Previously claimed	Why it is not here
Latency reduced 35%	No benchmark, no harness, no before-and-after. The same 35% appears elsewhere on my site attached to activation, which suggests one number was reused for two purposes.
1,200+ waitlist signups in 30 days	No campaign artifact or signup source. The live product has no waitlist mechanic.
7-day retention up 28%	No cohort definition, analytics platform or measurement window.
Activation improved 35%	See the first row.
40+ musician interviews	The research happened. The count has no log behind it.
3 major releases	No changelog or release history available.

A testimonial attributed to Veena Studio's founder also appears in a machine-readable file on my site. I have no permission trail for it and it appears nowhere a human would see. It is excluded here and flagged for deletion at source. Publishing an unsourced quotation from a named real person is the most serious thing in my current site and it needs to go regardless of whether the sentiment is accurate.

What can be verified: the company is real, the product is live, the pricing is public, the feature set is documented, and four design screens from this work exist. The role's substance is describable. Its outcomes are not measurable from where I sit, and that is partly a consequence of not having instrumented them, which is section 14's problem.

14 · What went wrong

I did not instrument my own work. This is the core failure and it is the one that produced everything in section 13. A product manager whose contribution cannot be measured has failed at part of the job, not just at reporting it. Activation, retention and feature adoption were things I said I tracked. If I had actually owned a defined metric with a dated baseline, I would have a result to report and, more importantly, I would have made better decisions while doing the work.

I let numbers into a portfolio that were not in a dashboard. Same failure mode as the TapQR write-up, same cause. A case study section headed "Outcomes" creates pressure to produce outcomes, and a plausible figure fills the space more comfortably than an honest gap. The gap is more credible. A founder reading "no outcome metrics exist, here is what was built" trusts the rest of the document. A founder who checks a 35% claim and finds nothing behind it stops reading.

I wrote user stories for a marketplace before there was a market. Plugin marketplace and collaborative marketplace specification work is intellectually satisfying and it was premature. A two-sided marketplace requires demand on both sides; specifying one before either exists is the most seductive way for a PM to look busy. That effort should have gone into activation on the single-player experience.

I described the product I found interesting rather than the product that shipped. My case study is about latency engineering and Web Audio internals. The product's own front page is about an AI producer. Both were true at different times, and I kept writing the earlier framing because it flattered a more technical self-image. That is a real distortion and a reader comparing my case study to the live product would reasonably wonder whether I was there.

My employment record for this role is internally inconsistent on my own site. Two different date ranges, two years apart, for the same job. However that happened, it is the kind of error that costs more trust than any missing metric, because it looks like carelessness about facts rather than absence of data. It is in the correction queue and it is why this document has no dates in it.

I underweighted the AI legitimacy question. The company's own FAQ leads with "Isn't AI in art bad?", which means it is the first thing a musician thinks. I treated that as a marketing concern. It is a product concern: it determines what the agent is allowed to do unasked, how provenance is surfaced, and what "music you own" has to mean technically. I did not push on it.

15 · What I learned

A founder's office PM's real output is decisions the founder no longer has to make. Not features shipped. Not documents written. The measure is how much throughput the company gains that does not route through one person. That reframing changed how I chose what to work on, and it arrived later than it should have.

In audio, timing is the feature. Not a quality attribute of the feature. The same capability delivered above and below the direct-manipulation threshold is two different products, one of which is unusable. This generalises to anything real-time and it is the thing I now check first.

Density is not the enemy. I came in with a default preference for reduction, which is right for most software and wrong for professional tools. Progressive disclosure on a mixer means hunting. Matching the user's existing mental model matters more than minimising what is on screen.

Strategy in a small company is choosing which future to foreclose. Fidelity and capability were both defensible. The cost of not choosing is worse than the cost of choosing wrong, because engineering effort split across two theories produces a product that is second-best at both. The clarity of the live product's current positioning is evidence that the choice got made.

Write the numbers down while they are true, or accept that you will never have them. Metrics cannot be reconstructed. This is now a rule.

Positioning against an objection beats positioning around it. "Music you own" is worth more than any feature bullet, because it answers the question that stops people from trying.

16 · What I would do differently

Own one metric with a dated baseline, in writing, in week one. Activation, defined precisely: a new user who imports or generates audio and exports something within their first session. One number, one definition, one dashboard, reported weekly. Everything else follows from having that.

Force the strategic choice earlier and in writing. A two-page document: fidelity versus capability, what has to be true for each, what each costs in engineer-months, what each forecloses. Not to make the founder's decision, to make it makeable. I believe I could have compressed that decision by a meaningful margin, and in a small company that is the highest-leverage thing a PM does.

Cut the marketplace work entirely. Redirect it at the empty session, which is where new users are lost. The blank page is the real churn surface in every creative tool.

Specify the agent's permission model before specifying its capabilities. What can the CoProducer change without asking? What is reversible, and is reversal total? How is generated material marked in the session so a user knows what came from where? These questions determine whether producers trust the product, and they are much harder to retrofit than to design.

Treat the AI legitimacy question as product scope. Provenance of generated material, clarity about training data, and a genuinely defensible meaning for "music you own". This is not messaging, it is architecture, and it is the difference between a tool musicians adopt and a tool musicians resent.

Keep the case study and the product in sync. One canonical description, updated when the product moves.

17 · Current status

Role: concluded or ongoing, pending date correction. Company: live and shipping. Design artifacts: published.

Item	Status
Veena Studio Inc.	Operating; live product at veena.studio, app at daw.veena.studio
Product positioning	Agentic DAW with an AI CoProducer
Pricing	Free tier at $0 with 5 CoProducer requests per day; Pro at $20 per month with 20,000 credits
Interface design screens from this work	4 published
My role dates	Unresolved on my own sources. Correction pending.
Outcome metrics	None evidenced. Six previously published figures removed.
Founder testimonial in my llms.txt	To be deleted; no permission trail

---

Related reading in this archive

• Designing products when AI is part of the interface: the agent permission problem from section 08
• AI features and AI-native products are not the same thing: the fidelity-versus-capability choice, generalised
• Designing for latency and trust in real-time products: the 0.1 second threshold and why it decides categories
• Why founders should care about activation before growth: the empty-session argument
• Designing trust in AI interfaces: provenance and reversibility as architecture
• Design systems under non-deterministic output: the component-level problem this product surfaced

Sources

1. Veena Studio product site: positioning, feature set, pricing, FAQ, community channels. https://www.veena.studio/
2. Veena Studio application. https://daw.veena.studio
3. Veena interface design screens, 4 published. https://devchopra.life/gallery
4. W3C, Web Audio API specification. https://www.w3.org/TR/webaudio/
5. W3C, WebAssembly Core Specification. https://www.w3.org/TR/wasm-core-2/
6. S. K. Card, G. G. Robertson and J. D. Mackinlay, "The information visualizer, an information workspace", CHI '91: origin of the 0.1s / 1s / 10s response-time bands.
7. Jakob Nielsen, "Response Times: The 3 Important Limits", Nielsen Norman Group, 1993. https://www.nngroup.com/articles/response-times-3-important-limits/
8. John Sweller, "Cognitive load during problem solving: Effects on learning", Cognitive Science 12(2), 1988.
9. MDN Web Docs, AudioWorklet and Web Workers reference for off-main-thread audio processing. https://developer.mozilla.org/en-US/docs/Web/API/AudioWorklet