dinhzu@gmail.com
D10 was built around one belief that context fragmentation slows teams more than poor task management. Most tools separate documentation and execution. We wanted to treat documentation as live infrastructure embedded directly inside work. As founding designer, I owned product direction, IA, system logic, and implementation quality end to end.
Role
Founding designer
Team of 2 (1 designer, 1 developer)
Responsibility
Without a product manager or research budget, I had to expand my role into product ownership: managing research, defining scope, and writing the documentation necessary to keep development moving without friction.
Challenges
This was a 2-person founding team. One designer, one developer. No PM, no spec writer, no existing product to reference, no documentation to start from.
Everything was ambiguous from day one. My job was to turn that ambiguity into something a single developer could actually build. That meant I wasn't just designing. I was:
Defining the product vision and scope
Running competitive research across 7+ tools
Building the full information architecture from zero
Designing the complete product — all views, all spaces, all logic
Writing functional specs and permission logic precise enough to build from
Prioritizing what ships first with the stakeholder
Doing QA against implementation
Starting From Research
I analyzed 7+ tools. Notion, Linear, ClickUp, Jira, Asana, Height, Fibery not just for features, but for the gaps nobody was talking about.
Notion excels at writing and block architecture, but lacks strong task governance
Jira is optimized for Scrum workflows, but rigid and complex for non-engineering teams
Linear offers clean execution UX, but limited documentation space
Fibery centralizes context using database driven docs, powerful but cognitively heavy
ClickUp and Asana provide visual task views, but documentation feels secondary
The finding that shaped everything: most tools solve either docs or tasks, never both. The few that tried kept them as separate modules with a thin bridge between them. From the resulted I started making IA, map out core features for and solution for the app.
Doc space
With D10, the doc space wasn't just a text editor. It was a structured, publishable environment meaning a team could maintain internal documentation and publish external facing content (changelogs, help docs, public roadmaps) from the same space.
I designed the full doc architecture: page hierarchy, block types, editor behavior, and the internal/external space distinction. The goal was that creating a doc felt as fast as opening Notion, but the content was always connected to the work happening in the task space.
Task views
Research shows task views are a top factor in platform choice not a nice to have. Different roles think differently.
So instead of picking one, I designed all five: List, Kanban, Calendar, Gantt, and Timeline on a single data model. Same tasks, same fields, same filters. Just rendered the way each role actually thinks.
Sync blocked - content centralized
Context scattered across tools is where projects actually break down. I adapted Notion's synced block pattern to solve this directly.
A synced block lives in one place but appears anywhere it's referenced. Update it once, it updates everywhere. The result: docs and tasks finally share the same context without duplication, without chasing the latest version.
An alternative approach involves using documents as structured databases.A method Fibery employs for context centralization. However, while this creates a unified source of truth, the learning curve can be steep for non-technical users who find the relational logic counterintuitive.
Scoping MVP
For MVP scope and limited resources of our agile environment, I prioritized the following core features:
Workspace and space creation (CRUD)
Internal and publishable doc spaces
Permission system and space sharing
Searching and filtering
UI trade off for faster development
AI integration could be a great helper to find context but skipped in MVP
Outcome
D10 reached a fully functional staging environment: internal workspaces, publishable doc spaces, permission system, and core doc editor all working. The full task space was designed and ready for the next build phase.
The project was pivoted by the stakeholder before the task space staged. The assessment: without significant funding, competing against Notion, Linear, and ClickUp's AI roadmaps in real-time wasn't a winnable position.
Takeaway
Building from zero with no PM isn't just a resource constraint, it's a different kind of design work. You're not filling a brief. You're writing it, questioning it, and executing it simultaneously. The skill isn't moving fast. It's knowing what to make real first.
MoSCoW kept us focused internally. It couldn't tell us when the market window was closing. That's not a framework problem, it's a validation problem. The real lesson: ship a testable hypothesis in 4–6 weeks, let behavior data drive the next decision, and treat competitive timing as an ongoing question, not a launch-day checkbox.