Product surface
Lab notebook. Product Surface models what a software product currently does through customer-facing areas and actions. An angled, partitioned plane lets teams select an area to explore its functional detail. It provides a shared product picture and a foundation for a product idea I have.
- STAGE
- Published
- BUILD TYPE
Applied AI- DECISION
- GoMoving to build. This will be my first Applied AI feature.
- STARTED
- Sept. 22, 2026
- PUBLISHED
- Nov. 5, 2026
- LAST UPDATED
- Nov. 5, 2026
Question
Can a customer-centered picture of a software product help a product manager quickly understand the whole product, explore its parts and build a shared understanding with their team?
In a previous role, I struggled to grasp the full picture of the platform I had inherited. Learning individual features did not give me a coherent understanding of the whole, and help connecting the pieces was hard to find. Product Surface is the tool I wished I had.
It is for both the PM learning an unfamiliar product and the PM who knows a product well but needs to make that knowledge visible to others.
Hypothesis
A product model organized as Capability → Surface Area → Function can make functional scope easier to understand and discuss than scattered explanations or a delivery backlog alone.
The model starts with what the product currently lets people do, independently of customer feedback or architecture diagrams. A thin, angled, CAD-like plane gives that model a visible shape. Selecting a surface area reveals its customer functions while retaining the whole-product context.
The perspective is a design hypothesis, not the value by itself. It earns its place if it improves understanding without requiring people to learn complicated controls. A list view provides another way to explore the same product model.
Measurement of success
The primary criterion is quick comprehension by a product manager. I’ll consider the concept promising if a PM can use the surface to describe the product’s main areas and explore what people can do within them.
I also want to learn whether the visual helps a PM explain the product to a teammate or stakeholder. I have not yet tested either outcome with independent users.
What I found
Observation: I started with an ownership-first concept. In working through it with Claude and Notion, I realized it required too much explanation before delivering value. A matrix could describe assignments, but it did not provide the shared picture of the product I wanted.
Decision: Lead with what the product does. Start there.
Observation: The product as a customer uses it needs to be recognizable. Geographic terrain mocks did not match the model I had in mind. Mountains, contours and scenery added visual meaning without explaining customer functionality. A subsequent mock using FileHarbor, my fictional product, and a thin, partitioned plane was much closer to the picture in my head.
Decision: Use CAD-like precision and functional drill-down rather than literal topography. “Under the surface” means customer actions, not backend infrastructure.
Observation: This was my first time building an application with React and Claude Code. CSS transforms supported the intended visual without a dedicated 3D engine, but the plane needed several rounds of refinement. Automated checks helped, but I also needed to inspect and use the result.
Decision: Continue refining the interactive plane and adapt the tool to fit within the CMM Labs site.
Observation: The interface felt too flat and the list below the plane split the experience.
Decision: Add restrained color by capability and move controls and contents into collapsible side panes. I also chose a three-part release path: the design hypothesis with sample data, manual setup and LLM-guided setup.
Data
The demonstration uses FileHarbor, a fictional product knowledge repository for small professional-services teams. Its approved sample contains four capabilities, 10 surface areas and 30 functions.
The capabilities are:
- Knowledge Creation & Organization
- Knowledge Discovery & Distribution
- Content Governance
- Workspace Administration
The product facts and functional inventory were developed through explicit review. They are synthetic demonstration content, not observations from a real company or customer dataset. The approved reference supersedes the original six-area mock.
What I did
- Started with a question from my own experience: How can a product leader see and share the full picture of what a product does?
- Shifted the concept from diagnosing ownership to creating a visual, shared understanding of the product.
- Explored visual directions and developed FileHarbor as a fictional product for testing the angled plane and its organization: Capability → Surface Area → Function.
- Used Claude Design and Claude Code to turn the concept into an interactive tool, refining the visual design and controls through successive reviews and handoffs.
- Chose a three-part release path, beginning with the design concept and sample product, followed by manual onboarding and then AI-guided creation.
What surprised me
The useful “wow” was not elaborate scenery. It was seeing a product understanding take a shape I could recognize and explore.
Starting with a tangible result helped clarify the specification. Writing the handoff then exposed gaps, including export grouping and how to create an area without assigning a capability.
The build used browser capabilities and CSS rather than adding a 3D engine. That kept dependencies down, but it did not make the geometry effortless: missing `preserve-3d` settings in ancestor elements caused multiple flattening bugs.
A green verification run could coexist with a blank printed page. Visual inspection was a separate, necessary activity.
The product picture has value before any customer signal is attached. Understanding the product is useful on its own; connecting signal to that picture is a separate, later idea.
Under the hood
Product Surface is built with React, TypeScript and CSS. At its core is a structured document that describes what a product does: capabilities group related surface areas and each area can contain the functions customers perform. The interactive plane and list views are generated from those same records, so they present different views of the same product picture. Each record has a stable ID separate from its display name. Work is saved locally in the browser, not synced to the cloud, and can be exported for use outside the tool. AI assisted with the design and implementation, but an in-product AI setup helper has not been built.
Current status and next steps
Part 1 is live: the design concept and hypothesis are available to explore with FileHarbor sample data.
Next, I plan to make it possible for someone to create a Product Surface for their own product through manual setup. The third part will add LLM-guided setup. That will be my first applied AI build with evaluations, so I want to take the time to design and test it well.
Automated checks and visual inspection have supported the build, but they do not establish complete accessibility or browser compatibility. Independent comprehension testing remains ahead.
Let’s talk.
You don’t need an agenda or a problem to reach out. I love to connect and share ideas!
Let’s talk