Reading frameworks, watching talks, or building isolated side projects never felt representative of how product decisions are actually made on real teams — where tradeoffs, constraints, and accountability exist whether you’re ready for them or not. So instead of simulating product work, I set up a real environment to practice it.
The company context
To create a realistic TPM learning environment, I needed a real organizational context — not just projects.
I set up Kurocado Studio as a boutique, creative software development studio. At a high level, the studio exists to design and build products and websites, with a focus on modern frontend engineering, design systems, and scalable UI platforms.
The structure of the company directly shapes the kinds of products I build and why some of them are developed in the open.
Company-level advantages
Boutique studio model
Kurocado Studio operates as a small, focused studio, which enables hands-on execution and close ownership of decisions. This model prioritizes quality, craft, and system design over volume, shaping products that are built deliberately rather than optimized for throughput.
Product and client work mix
The studio balances internal products with client work, which makes shared infrastructure a necessity. Instead of building one-off solutions, this structure justifies investing in reusable platforms that can support multiple use cases over time.
Open-source friendly strategy
Parts of the studio’s work are developed in the open through public repositories and documentation. This allows core systems to be hardened through real usage and feedback while remaining commercially viable and aligned with client needs.
Design-led positioning
Design is treated as a first-class concern, not a layer added at the end. This emphasis on UI consistency, visual systems, and interaction quality makes design systems and tokens a foundational business asset rather than a supporting tool.
Long-term reuse mindset
Systems are built with the expectation that they will evolve, not be discarded. This favors platforms and internal products that can adapt over time instead of disposable demos or short-lived experiments.
Clear technical focus
The studio maintains a narrow technical focus on frontend platforms, tooling, and UI architecture. This constraint helps avoid unfocused experimentation and keeps product efforts aligned with the studio’s core strengths.
Creating real constraints (on purpose)
Forming an LLC wasn’t about starting a startup or pitching an idea. I needed it anyway to freelance — but it also created something more useful: real constraints.
Once work is attached to a business, decisions change:
- Security matters
- Architecture choices have consequences
- Tooling costs are no longer abstract
- Documentation stops being optional
- “Good enough” becomes a liability
Choosing systems that force hard decisions
I started with problem surfaces — systems that are difficult to build casually and force deliberate tradeoffs. Each product exists to stress a different dimension of product and engineering work.
FormKit
Built to explore complex frontend state management: schema-driven forms, validation, conditional logic, and long-lived workflows. This is where product decisions collide directly with implementation reality.
The Platform
Shared CI/CD, tooling, and domain utilities. This reflects the platform teams I’ve been part of for most of my frontend career and forces thinking about scale, ownership, and reuse.
Making product decisions first-class
To avoid turning this into a collection of repositories, I invested in tooling that forces explicit thinking upstream.
- Jira Product Discovery as the source of truth for problems, insights, and decisions
- Jira Software (Premium) to practice cross-team planning and dependency management
- Jira Compass to connect systems, ownership, and code
- Slack for operational signal and notifications — not decision-making
- GitHub Enterprise to model security, governance, and ownership under real constraints
What this environment optimizes for
This environment optimizes for:
- Decision clarity over speed
- Traceability over intuition
- Fewer “why did we build this?” moments
- Practicing product thinking under real constraints
It’s intentionally heavier than what a solo developer needs — the goal is fluency in real product environments.
References & influences
The environment and tooling described in this post are informed by real-world practices around product discovery, delivery coordination, and platform governance. These tools shape how problems are captured, decisions are sequenced, and systems remain traceable over time.
Atlassian Jira Product Discovery
