Overview
Bringing structure to the way creative studios work with clients.
Running a creative studio involves much more than producing good work.
Behind every project are proposals, payments, feedback, deliverables, approvals, and conversations that need to stay organized.
At Parallel Lab, many of these activities were managed across different tools, particularly WhatsApp and other communication channels.
While this approach made it easy to stay in touch with clients, it also meant that important project information could become scattered across conversations.
I wanted to explore what a more structured client-management experience could look like.
That idea became Studio OS, a web-based client-management platform designed to bring important studio–client interactions into a shared workspace.
The product brings together project visibility, proposals, payment-related workflows, updates, and client communication in a more organized environment.
I took on the product management and design responsibilities, working on the product direction, requirements, workflows, decisions, and coordination of development.
Studio OS also served as an opportunity to strengthen my experience building a software product beyond the interface.
The central idea was simple: make it easier for creative teams and their clients to stay aligned throughout a project.
The Challenge
When communication becomes the workflow.
Creative studios often rely on familiar communication tools to manage client relationships.
A client sends feedback through WhatsApp. A proposal is shared separately. Payment information lives somewhere else. Project updates are communicated through another conversation.
Each interaction may work individually, but together they can create a fragmented experience.
For the studio, this makes it harder to maintain a consistent view of a client's project.
For the client, it can create uncertainty about progress, deliverables, approvals, and what happens next.
At Parallel Lab, I saw an opportunity to explore a more organized way of handling these interactions.
However, I also recognized that the product idea came primarily from our internal experience and my interest in building a useful software product.
It wasn't based on extensive external customer research or evidence of widespread market demand.
That distinction mattered because it influenced how I approached the first version.
Rather than attempting to build a comprehensive agency-management platform, I focused on defining a smaller set of connected workflows that could be implemented and evaluated.
Product objectives
01. Centralize client information
Create a shared location for important project information and client-related activities.
02. Improve project visibility
Help studios communicate progress and keep clients informed about ongoing work.
03. Structure commercial workflows
Support proposals, payment information, and related client interactions.
04. Reduce fragmented communication
Provide a more deliberate alternative to relying entirely on disconnected message threads.
05. Establish a foundation for learning
Build a usable first version that could be tested internally before considering broader adoption.
The central question
How might we make studio–client collaboration more structured and transparent without introducing unnecessary administrative complexity?
My Approach
Turning an internal idea into a defined product.
I approached Studio OS as an opportunity to practice end-to-end product development, from understanding the workflow problem to making implementation decisions and evaluating the resulting application.
Stage 01 — Understanding the workflow
I began by examining the activities involved in managing client projects at Parallel Lab.
This included how we handled project communication, proposals, payment discussions, deliverables, and updates.
The aim was to identify which activities would benefit from having a more structured home.
Rather than treating every operational inconvenience as a separate feature request, I considered how these activities related to one another.
For example, a proposal, payment record, and project update may be separate pieces of information, but they all contribute to the client's understanding of an engagement.
This helped shape the product around connected workflows rather than a collection of unrelated tools.
Stage 02 — Defining the product scope
With the initial problem established, I worked on translating the idea into a defined product.
The requirements focused on the essential interactions between a studio and its clients.
These included managing client and project information, organizing proposals, supporting payment-related activities, and communicating progress.
I also considered what should remain outside the first release.
The intention was to avoid expanding the product into a full accounting, project management, or business operations platform before validating the core experience.
This created a more manageable foundation for design and development.
Stage 03 — Structuring the user experience
Studio OS needed to serve two connected perspectives.
The studio team: People responsible for managing projects, communicating with clients, and keeping work organized.
The client: Someone who needs to understand the status of their engagement, review relevant information, and respond when action is required.
I considered how each group would navigate the product and which information needed to be visible at different stages of a project.
The interface needed to support everyday tasks without requiring users to understand the studio's entire internal process.
This influenced the organization of the dashboard, client-related sections, project information, and supporting workflows.
Stage 04 — Working through implementation decisions
As development progressed, the project exposed practical constraints that required product decisions.
One example involved payments.
The original direction included payment integration through Paystack, but the necessary credentials were not initially available.
There were also considerations around transaction fees and the additional setup required for non-technical users.
Rather than making the entire payment experience dependent on one integration, we introduced a manual payment pathway.
This allowed the product to accommodate payment arrangements outside the gateway.
It was a useful example of how implementation constraints can influence product design without requiring the underlying user need to be abandoned.
Stage 05 — Reviewing the product
As the application took shape, I reviewed the implemented workflows against the intended experience.
Testing revealed that some sections were present in the interface but did not yet provide meaningful functionality or information.
This created a gap between what the product appeared to support and what users could actually accomplish.
I treated these findings as product-quality issues rather than purely visual defects.
The focus became identifying incomplete experiences, clarifying expected behaviour, and preparing the application for a more reliable first release.
Key Product Decisions
Making trade-offs between ambition, usability, and implementation. 01. Build around the client relationship
The decision
Focus Studio OS on the interaction between creative studios and their clients rather than attempting to manage every aspect of studio operations.
Why
The initial opportunity was to make client-related information and activities easier to organize.
Expanding immediately into unrelated operational features would increase complexity without necessarily improving that experience.
The trade-off
Studio OS would not replace every tool used by the studio.
The first version would concentrate on the workflows most closely connected to client management.
02. Treat the first version as a learning opportunity
The decision
Develop an internal first version before positioning Studio OS as a validated commercial product.
Why
The idea originated from our own workflow and interest in building a product.
Although the problem was meaningful to us, we had not yet established how widely it was shared by other studios.
The trade-off
The initial release would prioritize functionality and internal learning over broad feature coverage or aggressive market positioning.
03. Introduce manual payment support
The decision
Provide a manual payment pathway alongside the intended payment-gateway integration.
Why
The initial Paystack integration depended on credentials that were not yet available.
Manual payment support also offered a practical alternative for studios that preferred direct transfers or did not want to configure a gateway immediately.
The trade-off
Manual payments require a different approach to recording and confirming payment status.
They should not be represented as automatically verified transactions.
This decision helped preserve the broader payment workflow without making the entire experience dependent on a single provider.
04. Prioritize meaningful functionality over visual completeness
The decision
Treat empty or incomplete product sections as issues requiring attention before the application could be considered ready.
Why
A dashboard can look finished while still failing to support the activities users expect.
If a section appears available but contains no useful functionality, it can undermine confidence in the product.
The trade-off
Additional refinement was necessary even after much of the interface had been built.
This shifted attention toward product completeness, useful states, and behaviour rather than visual polish alone.
05. Keep product decisions documented
The decision
Begin formalizing the product requirements and decisions made during development.
Why
As a product evolves, the reasoning behind changes can become difficult to reconstruct.
Documenting decisions helps explain why a feature exists, which alternatives were considered, and what assumptions still require validation.
The trade-off
Documentation introduces additional work, but it creates a clearer foundation for future iterations and collaboration.
Evidence of Work
From product concept to a functioning internal application.
Studio OS allowed me to work across product planning, experience design, implementation coordination, and quality review.
Product definition
I worked on defining the product's purpose, intended users, core workflows, and first-release boundaries.
The initial direction centered on improving how creative studios manage client relationships and project-related information.
Workflow design
I structured the experience around connected activities such as:
Client and project management
Proposal-related workflows
Payment information and payment handling
Project updates and progress visibility
Studio–client interactions
These workflows formed the basis of the product experience.
Interface and experience design
The application was designed to make project-related information easier to navigate and understand.
The interface includes dashboard and client-management experiences, with supporting sections for the activities involved in managing an engagement.
The design work considered information hierarchy, navigation, useful states, and the relationship between studio-facing and client-facing tasks.
Product decisions
One of the clearest documented examples was the decision to support manual payments when the planned gateway integration was constrained.
This required balancing the intended product experience with implementation feasibility and practical user needs.
Cross-functional delivery
I worked across product direction, design considerations, and development coordination as Studio OS progressed from concept into a functioning application.
This involved translating requirements into implementation priorities and reviewing whether the resulting experiences supported the intended workflows.
Quality assurance and refinement
Internal testing exposed incomplete sections and areas where the product needed clearer behaviour.
These findings informed further refinement and helped distinguish feature implementation from actual product readiness.
Product documentation
The project also prompted the creation and organization of product requirements and decision records to support future development.
Outcome & Reflection
Building the product was only the beginning.
Studio OS progressed from an internal idea into a functioning client-management application.
The first version brought together the core areas of the intended experience, including client and project information, proposals, payment-related workflows, and project updates.
It also exposed important product challenges.
Some features required further refinement, certain workflows depended on external services, and the application still needed internal quality assurance before it could be considered ready for wider use.
The project has not yet established verified customer adoption, revenue, retention, or productivity improvements.
For that reason, I consider its current outcome to be a functional first version and a foundation for further validation, rather than a proven commercial SaaS product.
What I learned
A product idea doesn't become validated simply because you build it.
Studio OS began with an internal problem and a desire to explore a better workflow.
Building the application helped make the idea tangible, but broader demand still needs to be tested with potential users.
Product management is a series of trade-offs.
The payment workflow demonstrated how technical constraints, business considerations, and user needs can influence the direction of a feature.
The goal is not always to preserve the original implementation plan. Sometimes it is to find another way to support the underlying need.
Feature completion and product readiness are different milestones.
An interface can contain the planned sections without providing a complete experience.
Testing those sections against real user tasks is necessary before treating them as finished.
Documentation protects product reasoning.
Requirements and decision records make it easier to understand why choices were made and what still needs to be addressed.
This becomes increasingly important as a product grows beyond its initial concept.
Building products requires thinking beyond the interface.
Studio OS strengthened my experience connecting workflows, requirements, design, technical constraints, and delivery decisions.
It also reinforced my interest in product management as a discipline focused on understanding problems, making informed choices, and guiding products through uncertainty.
Closing thought
A good product doesn't need to do everything. It needs to make the important things easier to do.
Studio OS started as an experiment in improving how a creative studio works with its clients.
It became an opportunity to practice the decisions involved in building software: understanding a workflow, defining priorities, managing constraints, evaluating functionality, and recognizing what still needs validation.
The next step is not simply adding more features. It's learning whether the experience solves a meaningful problem for the people it was designed to serve.
Product Management · SaaS Product Design · 2026
