# Kevin Canlas — full published content > Kevin Canlas is a Toronto-based product designer and design engineer creating thoughtful digital products across product, brand, motion, and frontend. Canonical site: https://www.kevincanlas.com/ This document is assembled from the site's published Markdown documents. It does not include drafts, API responses, or request-time data. --- title: "Kevin Canlas — Product Designer & Design Engineer" canonical: "https://www.kevincanlas.com/" --- # Kevin Canlas — Product Designer & Design Engineer Canonical: [https://www.kevincanlas.com/](https://www.kevincanlas.com/) ## Speed is cheap. Function is expected. Craft is *rare.* I’m a lead product designer and design engineer. Currently leading UI/UX at Monad Foundation, previously at Cyfrin and Molekule. I work across product, brand, motion, and frontend—turning ambiguous goals into coherent, shipped experiences. Comfy in canvas and code. ## Writings [All writings](https://www.kevincanlas.com/writings) ### [The Feature Works. The Product Doesn't.](https://www.kevincanlas.com/writings/the-feature-works-the-product-doesnt) When AI makes the answer to “can we build it?” almost always yes, product judgment becomes the work that protects coherence. 7 min ### [Taste in the Age of AI](https://www.kevincanlas.com/writings/taste-in-the-age-of-ai) AI can generate polished work faster than ever. Taste is still the judgment that decides what lands. 6 min ### [A Developer's Guide to Product Design](https://www.kevincanlas.com/writings/a-developers-guide-to-product-design) A practical process for developers to protect product coherence as features accumulate: define the problem, explore alternatives, map the journey, test risk, and spend craft deliberately. 8 min ## Skills [Explore skills](https://www.kevincanlas.com/skills) ### Product Judgement 4 Skills Focal, Compass, Flywheel, and Soul—four Markdown Skills for making coherent product-design decisions with AI. ## Recent roles Current & previous ### [Monad Foundation](https://www.monad.xyz/) **UI/UX Lead · Design Engineer** · May 2024–Present Leading design and development across Monad’s websites, products, ecosystem programs, and internal initiatives, while providing design support to ecosystem startups. ### [Cyfrin](https://www.cyfrin.io/) **Lead Designer** · Mar 2023–May 2024 Led design across Cyfrin, CodeHawks, Solodit, and Updraft for smart-contract security and education. ### [Molekule](https://molekule.com/) **Lead Designer** · Jul 2022–Feb 2023 Led product and interface design across commerce, web, mobile, and enterprise products. ## Recent work Current work for the Monad ecosystem. ### Monad.xyz Monad Foundation · Product, brand & frontend The main Monad Foundation website at monad.xyz, where I help shape the product, brand, motion, and frontend experience across the ecosystem. ### BuildAnything Monad learning platform · Product, UI/UX & design engineering BuildAnything helps developers move from vibe-coded prototypes to production-ready apps through guided learning tracks covering security, authentication, payments, and other production fundamentals. I worked across product, UI/UX design, and design engineering, and built the majority of the frontend. ### evm/accathon Monad hackathon · UI/UX, branding, motion & development For Monad’s evm/accathon at hackathon.monad.xyz, I executed the entire project end to end—from design and branding through motion and development. ## Earlier work (before AI) A few of my favourite interactive projects, preserved as working snapshots. ### Prolific Digital Agency work · UI design & frontend development At Prolific Digital, a full-service web and brand design agency, I worked as a UI designer and frontend developer across dozens of client projects. I designed and prototyped websites in Figma, then built them from scratch with HTML, CSS, JavaScript, React, Next.js, PHP, Laravel/Blade, and WordPress. ### Isekai Meta Ethereum NFT · UI/UX & creative frontend I joined Isekai Meta as its 13th team member and was responsible for UI/UX and creative frontend development across the website and minting experience. The community- and story-driven, hand-drawn Ethereum NFT collection was influenced by pop culture, lo-fi aesthetics, Japanese anime and manga—especially Studio Ghibli and Hayao Miyazaki—and sold out for roughly $2.7 million in ETH in July 2022. Tools and stack: Figma, React, Next.js, SCSS, GSAP, and Framer Motion. ### Solarians Solana NFT · UI design & frontend development As Solarians’ UI designer and frontend developer, I revamped the entire website and designed and built new product features. The NFT project lives in the Solana ecosystem. Tools and stack: Figma, SvelteKit, Tailwind, SCSS, GSAP, and Three.js. ### Franky’s Dinner NFT project · Design & frontend development Franky’s Dinner was a small NFT project built by a four-person team and inspired by 1920s rubber-hose animation. I designed and developed its landing page and minting experience. The collection sold out for roughly $600,000. ## Connect I’m not taking on freelance projects right now, but I’m always happy to meet thoughtful designers and developers. - [X / Twitter](https://x.com/kvncnls) — @kvncnls - [LinkedIn](https://www.linkedin.com/in/kevincanlas) — Kevin Canlas - [GitHub](https://github.com/kvncnls) — @kvncnls - [Email](mailto:kvncnlsdsgns@gmail.com) — Say hello --- title: "Skills — Kevin Canlas" canonical: "https://www.kevincanlas.com/skills" --- # Skills — Kevin Canlas Canonical: [https://www.kevincanlas.com/skills](https://www.kevincanlas.com/skills) ## Put product judgement back in the loop. Four Markdown Skills for making better product decisions across the screen, journey, relationship, and memory. They work in Claude Code, Codex, ChatGPT, Cursor, and any tool that can read Markdown. The umbrella is coherence: focused within a screen, navigable across a journey, valuable across the relationship, memorable after the experience, and trustworthy throughout. [View Product Judgement on GitHub](https://github.com/kvncnls/product-judgement) ## Why these exist Judgment before output Implementation got faster, and product judgment became easier to skip. When building is this easy, teams often skip the canvas entirely: Paper and Figma let you explore several directions at once, while code moves linearly and makes it easy to choose one path before you’ve considered the alternatives. Features then accumulate, screens crowd, flows turn into mazes, value gets buried, and working products become forgettable. [Read the article: “The Feature Works. The Product Doesn’t.”](https://www.kevincanlas.com/writings/the-feature-works-the-product-doesnt) These Skills help mitigate the limits of linear building while complementing the design process of seasoned designers. They give teams a way to examine alternatives and make more deliberate decisions in code. They encode principles, decision trees, failure modes, audit rubrics, exceptions, and fixed outputs so an AI can reason about an experience as a connected system—not generate one plausible screen at a time. ## The system Four Skills · Four scales ### Product Judgement **Scale:** Holistic Runs all four Skills against one evidence map, preserves their boundaries, reconciles related findings, and returns one prioritized fix sequence. It’s not a fifth scale. Use it when the question spans an app or several Skills identify related issues. [View Skill](https://github.com/kvncnls/product-judgement/tree/main/product-judgement) ### Focal — One screen, one clear intent. **Scale:** Screen Decides what belongs, what waits, and what wins attention through Information Architecture, Progressive Disclosure, and Visual Hierarchy. Use it when a screen feels crowded, unclear, or unable to make its organizing intent legible. [View Skill](https://github.com/kvncnls/product-judgement/tree/main/focal) ### Compass — Never lost. **Scale:** Journey Guides multi-screen flows through Orientation, Path Economy, and Continuity so context and state survive every seam. Use it when a flow has too many steps, weak orientation, dead ends, broken retreat, or lost state. [View Skill](https://github.com/kvncnls/product-judgement/tree/main/compass) ### Flywheel — Earn the second visit. **Scale:** Retention Finds the earliest place momentum drops across four ordered plays: Trust, Friction, Wins, and Emotion. Use it when people don’t trust the product, reach or recognize value, return, or bring others. [View Skill](https://github.com/kvncnls/product-judgement/tree/main/flywheel) ### Soul — Never boring. **Scale:** Craft Sorts the happy path into Expected, Elevated, and up to three Net-New moments so craft is concentrated where it earns memory. Use it when the product works but its happy path feels generic, forgettable, or over-designed. [View Skill](https://github.com/kvncnls/product-judgement/tree/main/soul) ## Boundaries and limitations Context, scope, and evidence These Skills complement design systems. A design system standardizes how decisions are rendered; these Skills help decide which decisions should be made. They work best with context: direct access to the product codebase, or a detailed product requirements document or design specification. Without it, recommendations are more likely to rely on assumptions. They don’t replace product strategy, user research, analytics, accessibility, security, legal review, or product knowledge. Without goals, audience, stakes, constraints, and evidence, the output is a hypothesis to validate—not a fact. ## How to use For designers and developers ### Designers Start with Paper or Figma. Point the Skills at your designs and ask them to audit, modify, or create interfaces. Use a collection of frames when you want Compass to understand the journey between screens, and use Focal when you’re evaluating a single screen. Give the LLM as much context as you can. Detailed design specs, product requirements, and access to the codebase show what the interface is trying to do, not just what it looks like. Have Product Judgement create variants of your frames, then converge on the strongest solution using your own judgment. ### Developers Code is a powerful place to build, but it’s a difficult place to explore several product directions at once. If you’re a founder-developer, it’s easy to move straight into implementation and leave product judgment for later. Start with Compass: give it the product features and ask whether the flow offers the right journey for users. Then use Focal to work through each screen. Features can easily pile on top of one another, creating incoherent experiences, UI clutter, and main flows that get deprioritized. After all, when five buttons compete for attention, where’s the user supposed to go? Focal helps you decide what belongs on the screen, what waits, and what deserves the user’s attention. If users aren’t returning, use Flywheel to find where the flow loses momentum. Analytics tools such as PostHog can show you where behavior changes, but they work best alongside product judgment; many likely drop-off points are visible in the journey itself. If the app feels generic, reach for Soul to analyze the happy path and decide which moments should feel **Expected**, **Elevated**, or **Net-New**. ## Installation [View repository](https://github.com/kvncnls/product-judgement) Start with the smallest scale that owns the problem. Use Product Judgement when the question crosses scales and you need one prioritized sequence. ### Global ```sh npx skills add kvncnls/product-judgement --skill '*' -g -y ``` ### Codex ```sh npx skills add kvncnls/product-judgement --skill '*' -a codex -y ``` ### Claude ```sh npx skills add kvncnls/product-judgement --skill '*' -a claude-code -y ``` ### Cursor ```sh npx skills add kvncnls/product-judgement --skill '*' -a cursor -y ``` --- title: "About — Kevin Canlas" canonical: "https://www.kevincanlas.com/about" --- # About — Kevin Canlas A concise account of Kevin Canlas’s design and engineering practice, experience, and selected work. Canonical: [https://www.kevincanlas.com/about](https://www.kevincanlas.com/about) ## What I do Kevin Canlas is a Toronto-based product designer and design engineer. He works across product, brand, motion, and frontend, turning ambiguous goals into coherent, shipped experiences. The practice moves between canvas and code: framing the problem, shaping the interface, and helping bring the result into production. ## Experience ### Monad Foundation [Monad Foundation](https://www.monad.xyz/) · **UI/UX Lead · Design Engineer** · May 2024–Present Leading design and development across Monad’s websites, products, ecosystem programs, and internal initiatives, while providing design support to ecosystem startups. ### Cyfrin [Cyfrin](https://www.cyfrin.io/) · **Lead Designer** · Mar 2023–May 2024 Led design across Cyfrin, CodeHawks, Solodit, and Updraft for smart-contract security and education. ### Molekule [Molekule](https://molekule.com/) · **Lead Designer** · Jul 2022–Feb 2023 Led product and interface design across commerce, web, mobile, and enterprise products. ### Earlier practice At Prolific Digital, a full-service web and brand design agency, Kevin worked as a UI designer and frontend developer across dozens of client projects. He designed and prototyped websites in Figma, then built them from scratch with HTML, CSS, JavaScript, React, Next.js, PHP, Laravel/Blade, and WordPress. ## Selected work Current work includes Monad.xyz, BuildAnything, and Monad’s evm/accathon. BuildAnything helps developers move from vibe-coded prototypes to production-ready apps through guided learning tracks covering security, authentication, payments, and other production fundamentals. For evm/accathon, Kevin executed the project end to end across design, branding, motion, and development. Earlier case studies include Isekai Meta, Solarians, and Franky’s Dinner. Isekai Meta was a hand-drawn, story-driven Ethereum NFT collection for which Kevin worked across the website and minting experience. Solarians was a Solana project where he redesigned the website and built new product features. Franky’s Dinner was a small NFT project whose landing page and minting experience he designed and developed. ## On this site The [portfolio](/) documents current and earlier interactive work. [Writings](/writings) cover product judgment, craft, and building things people can understand and use. [Skills](/skills) packages a four-scale product-judgment system as Markdown Skills for designers and developers working with AI. --- title: "Contact — Kevin Canlas" canonical: "https://www.kevincanlas.com/contact" --- # Contact — Kevin Canlas Public email and social links for reaching or following Kevin Canlas. Canonical: [https://www.kevincanlas.com/contact](https://www.kevincanlas.com/contact) ## Public ways to reach me This page lists the public contact and profile links already used by the site. Email is the direct route shown here. X / Twitter, LinkedIn, and GitHub are public profiles where you can follow the work, background, and code that Kevin chooses to share. - [Email](mailto:kvncnlsdsgns@gmail.com) — kvncnlsdsgns@gmail.com - [X / Twitter](https://x.com/kvncnls) — @kvncnls - [LinkedIn](https://www.linkedin.com/in/kevincanlas) — Kevin Canlas - [GitHub](https://github.com/kvncnls) — @kvncnls ## What these links mean The email link opens your mail application. The profile links take you to services that operate independently from this site. Those services control their own messaging, visibility, account access, and availability. This site does not promise a response time, availability for a project, project fit, or a particular outcome. There is no contact form, booking calendar, sign-in area, or private contact directory on this site. Use the public links above when you want to get in touch or review the public work associated with Kevin Canlas. --- title: "Privacy — Kevin Canlas" canonical: "https://www.kevincanlas.com/privacy" --- # Privacy — Kevin Canlas A technical description of the analytics, browser preferences, previews, and data requests observable in this site’s current code. Canonical: [https://www.kevincanlas.com/privacy](https://www.kevincanlas.com/privacy) ## Scope of this page This is a plain-language description of behavior visible in the current site code. It is not a complete account of how Google, GitHub, Coinbase, X, an email provider, or the hosting provider process information, and it does not make retention, legal-basis, deletion, or availability promises for those services. Their own policies and infrastructure govern the requests they receive. ## Analytics The site includes Google Analytics through `components/google-analytics-lazy.tsx`. The configured measurement ID is `G-BCSL80T0KW`. The code loads `https://www.googletagmanager.com/gtag/js?id=G-BCSL80T0KW` and initializes `gtag` with that ID using Next.js’s `lazyOnload` strategy, so the request is scheduled after the page has loaded. Loading that script can send page and browser information to Google. This site’s source does not define Google’s retention or processing rules. ## Browser preferences The color-theme control reads and writes the `kvncnls-color-theme` localStorage key with the values `light` or `dark`. The sound control reads and writes `cuelume-sound-enabled`; the value `false` disables interaction sound and any other stored value leaves sound enabled. These preferences are stored in the browser profile so the selected appearance and sound state can be restored on a later visit. The site’s API handlers do not read these keys or use them as account data. ## Public previews and outside services The MON market preview requests this site’s `/api/mon-price` endpoint and, while the live preview is active, can open a browser WebSocket to `wss://ws-feed.exchange.coinbase.com` for ticker updates. The site endpoint also fetches public ticker and candle data from Coinbase Exchange. No API key is required by this site’s route. The GitHub contribution preview requests this site’s `/api/github-contributions` endpoint. That server route reads the public `kvncnls` contribution calendar from GitHub. The social previews for X / Twitter and GitHub use image assets bundled with this site; following their profile links takes you to those third-party services. A third-party service can receive the request when a browser follows an external link or when a server-side preview route reads its public data. ## Hosting and data requests A request for a page, stylesheet, script, image, video, or API response is handled by the service hosting the deployed site. The current repository has no sign-in, comments, uploads, payment flow, or site-managed user database. The public API routes are read-only and do not require an API key. The site can still receive ordinary request information needed to serve HTTP traffic, such as the requested path and information carried by the request; this page does not claim a retention period for hosting logs. The market response is sent with `Cache-Control: private, no-store`; the server may keep fetched candle history in memory for up to five minutes while serving that route. The GitHub response uses `public, max-age=0`, an `s-maxage` ending at the next midnight in `America/Toronto`, and `stale-while-revalidate=300`; the server keeps one rolling-year response in memory until that refresh point. These are cache controls, not promises about third-party retention. The optional API quota feature, when configured, uses a trusted client IP address to derive an HMAC-based pseudonymous counter key in a shared Redis store. The request counter expires with its quota window; the raw IP address is not sent as the counter key. This does not make request metadata anonymous or define the hosting or database provider's logging policies. No quota store is used when the feature is unconfigured. See the [API rate-limit documentation](/developers#rate-limits) for request and caching behavior. ## Limits and requests This site does not currently expose an account export, correction, deletion, or consent-preference dashboard. If you have a question about this site’s pages or code, use the public address on the [Contact](/contact) page. Requests about analytics, GitHub, Coinbase, X / Twitter, email, or hosting data need to be directed to the service that controls that data. Nothing on this page should be read as a promise that a third party will retain, remove, disclose, or respond to a request in a particular way. --- title: "Developer documentation — Kevin Canlas" canonical: "https://www.kevincanlas.com/developers" --- # Developer documentation — Kevin Canlas Read-only documentation for the public JSON previews, discovery resources, errors, caching, and repository CLI. Canonical: [https://www.kevincanlas.com/developers](https://www.kevincanlas.com/developers) ## Kevin Canlas API documentation This site exposes small, public, read-only resources rather than an account or developer dashboard. No API key, signup, OAuth flow, or authentication header is required for the documented GET routes. The data can be temporarily unavailable when a documented public upstream source is unavailable. - [OpenAPI specification](https://www.kevincanlas.com/openapi.json) — machine-readable contract for the two JSON data endpoints. - [API catalog](https://www.kevincanlas.com/.well-known/api-catalog) — linkset for the actual public API endpoints. - [Markdown version of this documentation](https://www.kevincanlas.com/developers.md) — the same resource in Markdown. - [llms.txt](https://www.kevincanlas.com/llms.txt) and [full published content](https://www.kevincanlas.com/llms-full.txt) — concise and expanded site indexes. - [Sitemap](https://www.kevincanlas.com/sitemap.xml) — published HTML routes, excluding API responses and drafts. ## API discovery ### GET /api The API index describes the two public data routes, their documentation, the OpenAPI specification, and the authentication policy. It returns JSON with `authentication: "none"` and is useful when a client needs to discover the service before selecting an endpoint. It is cached with `Cache-Control: public, max-age=3600`. ```sh curl -i https://www.kevincanlas.com/api ``` The index is a discovery document, not a replacement for the endpoint schemas below or the [OpenAPI specification](https://www.kevincanlas.com/openapi.json). ## Versioning and deprecation policy Use `/api/v1/mon-price` and `/api/v1/github-contributions` for the explicit version 1 contract. The existing `/api/mon-price` and `/api/github-contributions` paths remain version 1 aliases and return the same payloads directly, without redirects. Existing portfolio behavior is unchanged. Version 1 preserves the documented field names, types, units, and meanings. An incompatible contract requires a new major-version path, such as `/api/v2/`; the unversioned aliases will not silently switch versions. Current timestamps and public upstream data remain variable by design. No version or alias is currently deprecated, and no removal date is scheduled. If a route is deprecated later, this page will document the migration and affected URLs, and its responses will include the [RFC 9745 Deprecation header](https://www.rfc-editor.org/rfc/rfc9745.html) as a Structured Field date. A scheduled removal will also use the [RFC 8594 Sunset header](https://www.rfc-editor.org/rfc/rfc8594.html) as an HTTP date, not earlier than the deprecation date. These headers are absent while no deprecation or removal is scheduled. ## Public endpoints ### Function-call inputs Both data operations take zero arguments: no path parameters, query parameters, or request body. The OpenAPI operations explicitly declare an empty `parameters` array. When adapting a GET operation to a function tool, use the operationId as its name, its description as guidance, and the empty-object input schema below. Execute the documented GET URL without a body; do not invent arguments just to create a non-empty schema. ```json { "type": "object", "properties": {}, "required": [], "additionalProperties": false } ``` ### GET /api/mon-price Returns the current MON-USD market preview and the seven-day hourly history used by the portfolio. It accepts no parameters and requires no authentication. The response is read-only market data from Coinbase Exchange; it is not trading advice. The JSON response contains `product` (`"MON-USD"`), `currency` (`"USD"`), `source` (`"Coinbase"`), `windowSeconds` (`604800`), `points` (chronological `{ time, value }` entries), `value`, `changePercent`, `low`, `high`, and `asOf` (the source timestamp). `time` values are Unix seconds; `asOf` is an ISO 8601 timestamp. ```sh curl -i https://www.kevincanlas.com/api/v1/mon-price ``` Caching: successful responses send `Cache-Control: private, no-store`. The server may reuse candle history in memory for up to five minutes, while the current ticker is fetched without a framework or upstream cache. A caller should treat values and timestamps as changing data. ### GET /api/github-contributions Returns the public contribution calendar for the fixed GitHub account `kvncnls` over a rolling 365-day window ending on the current date in `America/Toronto`. It accepts no parameters and requires no authentication. The route reports the public calendar it can read; it does not promise completeness if GitHub changes, limits, or withholds that source. The JSON response contains `username`, `totalContributions`, `startDate`, `endDate`, `days`, `timeZone`, and `nextRefreshAt`. Each `days` entry contains an ISO date, a non-negative `count`, and GitHub’s contribution intensity `level` from `0` through `4`. ```sh curl -i https://www.kevincanlas.com/api/v1/github-contributions ``` Caching: successful responses send `Cache-Control: public, max-age=0, s-maxage=, stale-while-revalidate=300`. The server keeps one rolling-year response in memory until the next Toronto midnight. Clients should read the returned `nextRefreshAt` when they need to understand the refresh boundary. ## Rate limits The site supports an optional shared, per-client fixed-window quota for GET and HEAD requests to the two data endpoints, including their version 1 aliases. All four URLs share the same bucket, so switching aliases does not reset a client's allowance. The site does not advertise an allowance unless a configured shared store has actually accounted for the request. When enforcement is active, responses include `RateLimit-Policy` and `RateLimit` using the [current IETF RateLimit draft](https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-ratelimit-headers-11), which is not yet a published RFC. For example, a configured allowance of 100 requests per 60 seconds would use `RateLimit-Policy: "public-api";q=100;w=60` and `RateLimit: "public-api";r=99;t=60` after the first request. These numbers illustrate the format; they are not a promised quota. Read the actual response headers for the configured allowance, remaining requests, and seconds until reset. An exhausted quota returns `429` problem JSON with `code: "rate_limit_exceeded"` and an integer-seconds `Retry-After` header. Wait at least that long before retrying. Quota-bearing responses are not shared-cacheable. If the quota service is unconfigured, cannot identify a trusted client, or is unavailable, reads remain available without quota headers; missing headers do not guarantee unlimited upstream capacity. The quota does not apply to HTML pages or discovery documents. ## Errors API errors use `application/problem+json`. The response has stable `type`, `title`, `status`, `detail`, `code`, and `resolution` fields; an `error` field can remain for compatibility with older callers. The `type` URLs below are documentation fragments, so clients can use them as stable identifiers and people can open the relevant explanation. ### Upstream unavailable HTTP status: `502`. Code: `upstream_unavailable`. Type: [`https://www.kevincanlas.com/developers#upstream-unavailable`](https://www.kevincanlas.com/developers#upstream-unavailable). The public Coinbase or GitHub source did not provide usable data. Retry the request later; the route does not turn an upstream failure into a fabricated success payload. ### API route not found HTTP status: `404`. Code: `api_route_not_found`. Type: [`https://www.kevincanlas.com/developers#api-route-not-found`](https://www.kevincanlas.com/developers#api-route-not-found). No documented public API route matches the requested `/api/...` path. Check the [API catalog](https://www.kevincanlas.com/.well-known/api-catalog) or [OpenAPI specification](https://www.kevincanlas.com/openapi.json). ### Method not allowed HTTP status: `405`. Code: `method_not_allowed`. Type: [`https://www.kevincanlas.com/developers#method-not-allowed`](https://www.kevincanlas.com/developers#method-not-allowed). The route is read-only. Use `GET` to read data or `HEAD` to inspect the response headers; unsupported write methods return a problem response with an `Allow` header. ### Rate limit exceeded HTTP status: `429`. Code: `rate_limit_exceeded`. Type: [`https://www.kevincanlas.com/developers#rate-limit-exceeded`](https://www.kevincanlas.com/developers#rate-limit-exceeded). The configured shared request allowance is exhausted. Respect `Retry-After`; sending requests to a version alias does not bypass the allowance. This response is possible only when shared quota enforcement is configured and operational. ```sh curl -i https://www.kevincanlas.com/api/does-not-exist curl -i -X POST https://www.kevincanlas.com/api/mon-price ``` ## CLI The [repository CLI entry point](https://github.com/kvncnls/kvncnls-site/blob/main/packages/cli/bin/kevincanlas.mjs) is a zero-dependency, read-only Node script for the same public resources. The deployed site publishes the exact source at [`/cli.mjs`](https://www.kevincanlas.com/cli.mjs), so you can download it, inspect it, and run it without installing an npm package. This is a repository-contained tool; no npm publication is claimed. ```sh curl -fsSL -o kevincanlas.mjs https://www.kevincanlas.com/cli.mjs sed -n '1,80p' kevincanlas.mjs node kevincanlas.mjs --help node kevincanlas.mjs profile --json ``` From a repository checkout, run the entry point directly. The commands below cover the profile, published writings, skills, OpenAPI document, and API catalog. Add `--json` for machine-readable output. Add `--base-url http://localhost:3000` when reading a local site instead of the deployed origin. ```sh node packages/cli/bin/kevincanlas.mjs profile node packages/cli/bin/kevincanlas.mjs writings --json node packages/cli/bin/kevincanlas.mjs skills --json node packages/cli/bin/kevincanlas.mjs api node packages/cli/bin/kevincanlas.mjs catalog --json node packages/cli/bin/kevincanlas.mjs api --base-url http://localhost:3000 node packages/cli/bin/kevincanlas.mjs catalog --base-url http://localhost:3000 --json ``` ## Discovery and Markdown The [OpenAPI specification](https://www.kevincanlas.com/openapi.json) is the contract for the two data endpoints. The [API catalog](https://www.kevincanlas.com/.well-known/api-catalog) points to those endpoints and this documentation. For content-oriented clients, read [llms.txt](https://www.kevincanlas.com/llms.txt), [llms-full.txt](https://www.kevincanlas.com/llms-full.txt), or the Markdown alternate at [developers.md](https://www.kevincanlas.com/developers.md). The [sitemap](https://www.kevincanlas.com/sitemap.xml) lists published HTML pages, not JSON responses or drafts. --- title: "Writings — Kevin Canlas" canonical: "https://www.kevincanlas.com/writings" --- # Writings — Kevin Canlas Canonical: [https://www.kevincanlas.com/writings](https://www.kevincanlas.com/writings) ## Design is how we decide what matters. Notes on product judgment, craft, and building things people can understand and use. ## Foundations The point of view ### [The Feature Works. The Product Doesn't.](https://www.kevincanlas.com/writings/the-feature-works-the-product-doesnt) When AI makes the answer to “can we build it?” almost always yes, product judgment becomes the work that protects coherence. 7 min ### [Taste in the Age of AI](https://www.kevincanlas.com/writings/taste-in-the-age-of-ai) AI can generate polished work faster than ever. Taste is still the judgment that decides what lands. 6 min ## Practice Methods to use now ### [A Developer's Guide to Product Design](https://www.kevincanlas.com/writings/a-developers-guide-to-product-design) A practical process for developers to protect product coherence as features accumulate: define the problem, explore alternatives, map the journey, test risk, and spend craft deliberately. 8 min --- title: "The Feature Works. The Product Doesn't." canonical: "https://www.kevincanlas.com/writings/the-feature-works-the-product-doesnt" --- # The Feature Works. The Product Doesn't. _Essay · Aug 14, 2026 · 7 min_ When AI makes the answer to “can we build it?” almost always yes, product judgment becomes the work that protects coherence. Canonical: [https://www.kevincanlas.com/writings/the-feature-works-the-product-doesnt](https://www.kevincanlas.com/writings/the-feature-works-the-product-doesnt) ## Key takeaways 1. AI made “could” cheap. The hard part is asking “should we?” 2. Features can make sense on their own and still make the product stop making sense as a whole. 3. Functional is a milestone. It isn’t a finished product. 4. Product judgment has to happen before the next feature is built, while you can still change what it does to the rest of the experience. ## Article While observing startups across tech build and ship at increasingly absurd speeds, I keep returning to a line from Jurassic Park: > “Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.” — Dr. Ian Malcolm > > ![Dr. Ian Malcolm in Jurassic Park](https://www.kevincanlas.com/assets/article/ian-malcolm.gif) That quote hits differently now that the answer to “can we build it?” is almost always yes. AI has completely changed the economics of building software: a feature can go from “maybe” to a live part of the product before the assumption behind it has been properly challenged. Today, the hard part is understanding what that one more thing does to the product as a whole. One feature leads to another, then another, until the product has a lot of functionality but nobody can clearly explain how all of it fits together. This is AI Product Slop, or simply Product Slop: when features make sense on their own, but the product stops making sense as a whole. ## When speed erodes coherence Product Slop rarely starts with a bad idea. The trouble begins when shipping speed becomes the dominant measure of progress. A referral program could help with growth. A points system could increase engagement. An AI assistant could help users find information. A social feed could build community. Each one sounds reasonable on its own. There’s also a temptation to turn every promising product into an “everything app”. If users like one thing, why not give them ten more? But the products people come back to usually have a clear reason to exist. They do one thing, or a small number of things, extremely well. You know what they’re for. Focus creates that clarity. Every new feature has to compete for attention with the thing that made the product useful in the first place. Jira and Linear are a good example. Jira grew into an extremely flexible product with customizable workflows, fields, permissions, and thousands of integrations. Linear took a more opinionated approach to how software teams work, and even says there are Jira features it has deliberately chosen not to pursue. It didn’t need to match Jira feature-for-feature to become compelling. Focus became part of the product. (This is a tangent, but I think another competitor will eventually take on Linear for the exact same reason they took on Jira. Feature creep gets the best of us.) And that is the broader pattern. Each addition can be useful on its own while the product becomes harder to understand as a whole. Zoom out and suddenly you have five competing priorities, several disconnected journeys, and no clear sense of what users are supposed to care about. That is the trap. The faster you add things, the easier it becomes to lose sight of what they’re doing to the product as a whole. ## Product Slop often comes with Visual Slop Both forms of slop come from the same pressure to move quickly, even though they appear at different layers of the experience. Visual AI Slop is the obvious stuff: generic styling, synthetic language, predictable layouts, awkward typography, and interfaces with no real visual point of view. The product feels like a first-pass AI output because, in many cases, it is. The problem is that users see all of this before they understand the value of the product. When everything looks and sounds like the same AI-generated template, it becomes harder to stand out, harder to feel memorable, and harder to signal that real care went into what you built. In products that involve money, identity, or risk, those details can also affect whether someone trusts the product enough to keep going. Fortunately, this surface is easier to repair and recognize. Stronger brand direction, clearer language, design QA, and a coherent design system can improve visual quality relatively quickly. Many Design Skills already repair that system across typography, layout, color, and more. [Jakub Krehel’s Better Interface Skills](https://github.com/jakubkrehel/skills), [Paul Bakaus’s Impeccable Styles](https://github.com/pbakaus/impeccable/tree/main), and [Emil Kowalski’s Skills](https://github.com/emilkowalski/skills) are great examples. Product Slop is buried deeper. It lives in the feature set, information architecture, onboarding, feedback, risk controls, core loop, and overall journey. Fixing it may require removing features, combining flows, changing priorities, or rebuilding parts of the product. A visual refresh can make an incoherent product look more polished without making it easier to use. ## Why coherence matters At some point, the product technically works. The wallet connects, the transaction executes, the data appears, and the feature behaves as expected. That’s usually the moment a team starts to feel done. But functional is a milestone. It isn’t a finished product. The product still has to make sense as an experience. Users need to understand what to do, what is happening, what matters, and what they should expect next. Sometimes how the product delivers value matters just as much as the value itself. That means answering a few basic questions: Can users tell what to do next? Do they understand what is happening? Do they know when they have won? Can they recover when something goes wrong? There is no universal answer. A trading app, social platform, game, and developer tool each need different forms of clarity, feedback, trust, tension, and reward. The right decision depends on the product, the user, and the moment. That is why product design is so difficult. In finance and crypto, the stakes are even higher. Users are being asked to connect wallets, sign transactions, and move money. The technology can work perfectly, but the experience still has to make people feel confident enough to continue. Good product design helps people understand what’s happening, reach value faster, and feel confident enough to return. ## How do we mitigate Product Slop? Product Slop is a judgment problem, so the repair has to begin before another feature reaches production. Product judgment needs to come back into the process before the team starts building. Step back from the feature, look at the whole journey, and ask what adding it actually does to the product. Does it strengthen the core journey? Does it make the product better at what people already come here to do? Does it introduce another competing priority? Does it make an existing behavior clearer? Does it create something new the user now has to understand? Does the added complexity earn its place? Stop judging every feature on its own. Look at what it does to the whole product. I wrote [A Developer’s Guide to Product Design](https://www.kevincanlas.com/writings/a-developers-guide-to-product-design) as the practical follow-up to this essay. It shows developers how to protect a product’s coherence as it grows: defining the problem behind each addition, exploring alternatives, mapping the journey, testing the riskiest assumptions, and deciding where craft belongs. This is also why I built the [Product Judgement Skills](https://www.kevincanlas.com/skills): four Skills that bring product judgment back into the loop. - **Compass** maps the product journey and helps you see where the experience breaks down. - **Focal** clarifies what each screen needs to communicate and what users should focus on. - **Flywheel** examines what gives people a reason to come back. - **Soul** helps you decide where the experience should stay Expected, become Elevated, or feel Net-new. Point them at your designs, product requirements, or codebase before you commit to a path. They’ll help you explore alternatives, protect the main journey, and spend craft where it matters. The final judgment is still yours. ## What this means for the tech industry Product Slop is happening across the tech industry. Early teams need rapid experimentation. They have to ship, learn, and figure out what users actually value. Some roughness is inevitable, and I don’t think every early product needs to arrive fully polished. The opportunity is to preserve that speed while becoming much more deliberate about what earns its place in the product. As software becomes easier to produce, shipping another feature becomes the easy part. The difficult work is deciding what belongs, how each addition changes the rest of the experience, which moments deserve more care, where familiar patterns are useful, and which ideas should never make it into the product. AI has made “could” cheap. We can build almost anything, and we can build it faster than ever. The question worth spending more time on is the one Ian Malcolm asked decades ago: *Should we?* ![Dr. Ian Malcolm: Your scientists were so preoccupied with whether or not they could that they didn’t stop to think if they should.](https://www.kevincanlas.com/assets/article/ian-malcolm-should.gif) ## Continue reading - [A Developer's Guide to Product Design](https://www.kevincanlas.com/writings/a-developers-guide-to-product-design) — A practical process for developers to protect product coherence as features accumulate: define the problem, explore alternatives, map the journey, test risk, and spend craft deliberately. (8 min) - [Taste in the Age of AI](https://www.kevincanlas.com/writings/taste-in-the-age-of-ai) — AI can generate polished work faster than ever. Taste is still the judgment that decides what lands. (6 min) [All writings](https://www.kevincanlas.com/writings) --- title: "Taste in the Age of AI" canonical: "https://www.kevincanlas.com/writings/taste-in-the-age-of-ai" --- # Taste in the Age of AI _Essay · Aug 27, 2026 · 6 min_ AI can generate polished work faster than ever. Taste is still the judgment that decides what lands. Canonical: [https://www.kevincanlas.com/writings/taste-in-the-age-of-ai](https://www.kevincanlas.com/writings/taste-in-the-age-of-ai) ## Key takeaways 1. Taste is effort made visible. It’s how you capture the moving line between foreign and familiar. 2. If the time AI saves simply becomes a shorter deadline, the baseline improves while the work stays generic. 3. AI will eventually predict what’s culturally trending in design, the way creators already try to catch viral trends. ## Article AI can generate polished interfaces, brands, and visuals faster than ever. But it still struggles with one of the things that separates work that merely looks good from work that actually lands: taste. Before getting into why AI has no taste and where AI might be going instead, it’s worth defining what taste actually is. ## Taste is good judgment under context Good taste sits somewhere between foreign and familiar: foreign enough to feel interesting, but familiar enough to feel acceptable. Push too far toward the foreign and you get discomfort, disgust, or something that reads as avant-garde. Fashion is a great example. A look can be genuinely new, technically impressive, and even ahead of its time, but still not land because most people aren’t ready for it yet. But if you push too far toward the familiar, you'll get boredom. It feels safe, predictable, generic. You’ve seen it too many times already. Taste is the ability to teeter on the line between foreign and familiar intentionally. Unfortunately, that line is never fixed. It depends on culture, timing, audience, and repetition. What feels fresh in one city, community, or moment might feel played out somewhere else. What looks strange today might become normal next year. Something can enter good taste at a specific moment, then exit it once it becomes too familiar. That’s why taste is hard to turn into a set of permanent rules: Its value comes from its relationship to the current cultural moment. ## Good taste is effort made visible That judgment doesn’t appear at the end of the process by accident. It comes from looking at references, exploring alternatives, and going far enough into the details to know what belongs. Effort is how you see it show up. The more effort you put into a product or brand, the more likely you are to arrive at a better answer, not because more time automatically makes the work better, but because time and effort creates room to explore. You reject the first plausible answer instead of mistaking it for the right one. You can feel when someone has pushed on the work. They know when to make something stranger, when to pull it back, and when to leave it alone. They make deliberate decisions about what they choose to push, what they pull back, what they remove, and what they refuse to accept as good enough. Good taste is effort made visible. It’s selection, restraint, refinement, and point of view. Bad taste is a lack of effort. Slop isn’t necessarily broken or ugly. It’s visibly under-considered: the work stopped at the first plausible answer. That’s why slop is so recognizable. It’s the visible absence of effort, and AI makes that absence much easier to see. ## AI raises the baseline AI also changes how effort shows up. People can get much further in less time, so the result can look more considered than pre-AI work even when the process involved less deliberate exploration. The default got better along with the speed. AI is so good at reading and reproducing old patterns that its standard outputs are now better than what most non-experts could create on their own. But if the baseline is already polished, effort can’t mean producing something that merely looks finished. Effort is effort, after all. Most prompts don't take any effort. This means you have to be willing to push beyond what AI produces by default: exploring further, going deeper into the details, and taking the design past the standard answer even when that answer is already good. The standard output may be convincing without being tasteful. The effort is in using the time AI gives back for that exploration, not in accepting the first polished result. AI can get a team to a competent baseline faster, but that only helps if the extra time goes back into exploration. If the time saved simply becomes a shorter deadline, the baseline improves while the work stays generic. AI is also changing the creative timeline. Execution is becoming a blip. A first interface, identity, or set of visual directions can be produced almost immediately. That shouldn’t make the rest of the process shorter. Exploration, ideation, brainstorming, references, and critique now need to take up the majority of the process. Otherwise AI simply makes the generic answer arrive faster. ## The mismatch Models are already very good at generating familiar design patterns. Many UX problems have strong precedent now: onboarding, navigation, settings, forms, dashboards, checkout flows. AI has seen enough examples to generate something usable very quickly. But a polished interface can still arrive without taste. AI learns from what already exists. It can reproduce patterns, combine references, and make variations at a speed no human can match. Taste often requires knowing when something has already become too familiar, when a visual language is exhausted, or when a new direction is just beginning to become culturally legible. That’s the mismatch. AI is fundamentally looking backward at what has been made. Taste is often about understanding what’s happening right now, and sometimes sensing what’s about to happen next. That’s why AI-generated design can drift toward the average. It can look finished and offend no one, and still have no real point of view. It can stack familiar patterns and features together without understanding the larger product, the cultural moment, or why one decision should exist over another. ## The person directing it AI is already useful for solving familiar problems, accelerating prototypes, generating variations, and reducing the cost of execution. With strong context, good references, and a research-first process, it can be genuinely helpful. The quality of the result still depends heavily on the person directing it. The output improves when you spend more time in planning, gathering references, exploring directions, and giving the system enough context to understand the actual problem. Generate a screen and ship it, and you get to the baseline faster. Use AI as part of a design process, and you have a chance of getting past it. I don’t think the goal is to inject taste into a model. Taste is too contextual, too cultural, and too dependent on the moment for that. Training on more historical examples or collecting more preference data may make models better at producing work people generally like. That’s different from knowing what’s timely, what’s stale, or what’s about to land. ## What is entering the moment If taste is partly the ability to read the moment, AI might be more useful helping us see what’s entering that moment than trying to have taste itself. Social media already has versions of this. Creators don’t just look at what’s popular. They try to spot what’s beginning to take off before it becomes saturated. The valuable signal is what might become culturally relevant next, not what everyone is already copying. Design will likely move in that direction too. AI may get better at surfacing emerging visual languages, interaction patterns, audience preferences, and cultural signals. It may help designers get closer to the edge, where something is new enough to matter but familiar enough to land. Someone still has to decide what’s worth pushing, what needs to be pulled back, what belongs in the product, and what should be removed entirely. > Taste is effort made visible—capturing the moving line between foreign and familiar. ## Continue reading - [The Feature Works. The Product Doesn't.](https://www.kevincanlas.com/writings/the-feature-works-the-product-doesnt) — When AI makes the answer to “can we build it?” almost always yes, product judgment becomes the work that protects coherence. (7 min) - [A Developer's Guide to Product Design](https://www.kevincanlas.com/writings/a-developers-guide-to-product-design) — A practical process for developers to protect product coherence as features accumulate: define the problem, explore alternatives, map the journey, test risk, and spend craft deliberately. (8 min) [All writings](https://www.kevincanlas.com/writings) --- title: "A Developer's Guide to Product Design" canonical: "https://www.kevincanlas.com/writings/a-developers-guide-to-product-design" --- # A Developer's Guide to Product Design _Field guide · Aug 16, 2026 · 8 min_ A practical process for developers to protect product coherence as features accumulate: define the problem, explore alternatives, map the journey, test risk, and spend craft deliberately. Canonical: [https://www.kevincanlas.com/writings/a-developers-guide-to-product-design](https://www.kevincanlas.com/writings/a-developers-guide-to-product-design) ## Key takeaways 1. Start with the problem. A feature request only gives you something to implement. 2. Judge every addition against the primary outcome and the whole journey, not its local usefulness. 3. Explore more than one answer before implementation gives the first one too much gravity. 4. Test the riskiest assumption before you build the system around it. 5. Use familiar patterns by default, add care where it improves understanding or trust, and reserve novelty for what defines the product. ## Article Products rarely lose coherence all at once. As momentum grows, feature requests accumulate and developers keep shipping each locally reasonable addition until the main journey loses priority. Product design is the ongoing practice of stepping outside the implementation, judging each addition against the whole experience, and deciding what belongs before another feature reaches production. This guide focuses on what to do next. If you want to understand the problem first, read [The Feature Works. The Product Doesn’t.](https://www.kevincanlas.com/writings/the-feature-works-the-product-doesnt) ## Start with the problem, not the feature Feature requests often arrive disguised as certainty. By the time work reaches a developer, a proposed solution can look settled even when the underlying problem is still vague. Before you add another route, component, or data model, make the problem specific. Who is this for? What are they trying to do? Where does the current experience break down? What would become meaningfully better if you solved it? What does the person need to understand, trust, or accomplish? If those answers aren’t clear, adding more screens only gives the product more surface area. The feature may work perfectly while the product around it becomes harder to understand. A clear problem gives you something to evaluate. A feature request only gives you something to implement. ## Choose the primary outcome Every feature has its own logic. A growing product still needs a hierarchy. Keep returning to the primary outcome: the thing someone should accomplish that makes the product worth using. Then protect the happy path, the shortest coherent route from their starting point to that value. The happy path isn’t the only path you’ll build. It establishes what the rest of the product is supporting. Onboarding, navigation, empty states, permissions, errors, and settings should help someone reach the outcome or clearly explain why they can’t yet. Without a primary outcome, each addition can demand equal attention. Navigation grows, controls multiply, and the product leaves people wondering what to do next. ## Explore alternatives before implementation creates commitment Once a feature enters the codebase, it accumulates gravity. Components exist. State has been wired up. The API shape starts reflecting the interface. Even if the direction weakens the product, replacing it now feels wasteful. Explore before that happens. Use Paper, Figma, FigJam, a whiteboard, or anything that lets you see several directions at once. The tool matters less than the distance it creates from your first answer. Look at references too. See how competitors and other great products solve similar problems. You’re not looking for something to copy. You’re trying to understand the patterns people already know, what seems to work, and where there might be room for a better answer. Good references also give you more than your first idea to work from. Pull from products inside your category and outside of it. Sometimes the best solution to a trading problem comes from a game, a social app, or a completely different kind of product. Make those directions meaningfully different. Try another information structure, a different core action, a shorter journey, or a different way to explain the product. Three versions of the same screen with different button styles aren’t three product directions. AI can help you create breadth quickly. Ask it for several interpretations, not endless polish on the first one. Generation gives you options. You still have to decide which option best serves the problem and why. Use a simple checkpoint before committing. It keeps a locally sensible addition from becoming permanent simply because it already works: - Keep: The convention already carries clarity, speed, or trust. - Refine: The structure belongs, but the hierarchy, language, feedback, or quality needs work. - Rethink: The purpose, flow, product model, or signature moment needs another answer. ## Map the journey, not just the components Developers naturally think in routes, components, and data states. People experience the seams between them. A component can work in isolation while the journey around it fails. Context disappears between screens. The next action is unclear. Feedback arrives too late. A risky decision asks for trust before the product has earned it. A Storybook story can prove that a component renders correctly; it can’t prove that the experience makes sense from beginning to end. Map the meaningful actions, decisions, system responses, waiting states, failures, and success states along the journey. Put the full sequence somewhere you can see it at once. Then ask the obvious questions. Does the person know what’s happening while they wait? Do they know what to do next? Is the feedback sufficient? Are wins acknowledged? Are risks and consequences clear? Can they recover from a mistake? Could a step be removed, combined, delayed, or reordered? These aren’t polish questions. They determine whether a set of working components becomes a coherent product. ## Prototype the riskiest assumption Developers often prototype technical feasibility: Can the API return the data? Can the model produce the output? Can the interaction run at 60 frames per second? Product prototypes answer a different kind of question. Will someone understand the next step? Will they trust the transaction? Can they recognize the value? Does the new behavior feel useful enough to replace what they do today? Test the riskiest assumption before you build the entire system around it. A click-through prototype, a rough canvas, or throwaway code can be enough. Put the direction in front of people, watch where they hesitate, and revise the product rather than automatically explaining the confusion away. A prototype should reduce uncertainty before it creates commitment. If you’re already protecting its architecture, you’re probably building too much. ## Bring the decisions into code Once a direction survives comparison and testing, bring it into production. Implementation is where the idea meets real content, responsive layouts, accessibility, performance, loading, errors, permissions, and messy data. That makes code another test of the product decision. Does the hierarchy survive a narrow screen? Do loading and error states preserve the same intent? Does the interaction still feel trustworthy when it takes longer than the demo? Does the distinctive moment remain useful after the novelty wears off? Keep the reasoning close to the implementation. The team should still know which outcome the feature supports, which trade-offs were deliberate, and which parts need evidence after launch. Otherwise, product decisions disappear one small implementation choice at a time. After launch, use behavior and feedback to find where the journey breaks down. Shipping gives you evidence about what to keep, refine, or rethink next. ## Spend craft deliberately Once the journey and its trade-offs are visible, decide where the experience should be familiar, where it deserves more care, and where novelty is worth its learning cost. Not every interaction needs to become a signature moment. ### Expected Expected moments use patterns people already understand. Navigation, inputs, settings, search, account management, and routine confirmations usually benefit from platform conventions and familiar components. Expected doesn’t mean neglected. It means you’re choosing reliability where reliability creates the better experience. ### Elevated Elevated moments keep the underlying interaction familiar while adding more care, clearer feedback, personality, or emotion. A pending action can explain what’s happening. A milestone can feel more rewarding. A risky decision can slow down and give someone enough context to proceed confidently. The pattern remains legible, but the moment feels specific to the product. This is where much of its personality can live without asking people to learn a new interaction every time. ### Net-new Net-new moments introduce an experience someone hasn’t encountered before. Reserve them for interactions that are central to the product’s value or identity, especially when the moment is worth remembering or sharing. Novel interactions also create implementation and learning costs. When every part of the product tries to be original, the experience becomes exhausting and the codebase becomes harder to maintain. A few genuinely new moments stand out because the rest of the journey gives them room. Most of the journey should remain Expected. Some moments should be Elevated. Very few need to be Net-new. That ratio isn’t a law. It forces you to decide where familiarity helps, where additional craft matters, and where novelty earns its cost. ## Protect coherence as the product grows Product design for developers isn’t one phase at the start of a project. It’s a recurring check on whether each addition strengthens the product or merely expands it. Before implementation, design identifies what deserves to exist, compares possible directions, and exposes weak assumptions. During implementation, it protects the hierarchy, journey, states, and trade-offs that made the direction worth choosing. After launch, it gives the team a clear model for interpreting what people do next. Momentum is useful when the product still has a clear direction. Give each addition a reason. The code should carry a decision you can explain, not another feature that happened to fit on the roadmap. ## Product Judgement Skills The process above still works on a canvas. I built the [Product Judgement Skills](https://www.kevincanlas.com/skills) so developers wouldn’t have to leave the IDE to use it. When implementation is cheap, the easiest thing to skip is the pause before you write the feature. Opening Figma, writing a spec, or waiting for a review can all feel like leaving the work. So the model gets asked to build, and product judgment happens later, if it happens at all. These Skills keep that judgment in the same loop as the code. You can prompt for the problem, the journey, the screen, the reason to return, or where craft belongs—without switching tools. - **Compass** maps the product journey and helps you see where the experience breaks down. - **Focal** clarifies what each screen needs to communicate and what users should focus on. - **Flywheel** examines what gives people a reason to come back. - **Soul** helps you decide where the experience should stay Expected, become Elevated, or feel Net-new. Point them at a design, a product requirement, or the code in front of you. They’ll help you explore alternatives, protect the main journey, and spend craft where it matters. The final judgment is still yours. > AI can make every addition cheap. Product design helps developers decide whether each one makes the whole product stronger. ## Try this before your next feature Stay in the editor. Point the [Product Judgement Skills](https://www.kevincanlas.com/skills) at the addition you’re about to write, and ask for a product decision instead of an implementation. 1. **Compass:** “Here’s the feature I’m about to add. Map the journey and tell me whether it strengthens the happy path or creates another competing one.” 2. **Focal:** “Look at this screen. What does it need to communicate, what can wait, and where should attention go?” 3. **Flywheel:** “After this change, what reason does someone have to come back? Where does the flow lose momentum?” 4. **Soul:** “Which moments here should stay Expected, which deserve to be Elevated, and is anything actually Net-new?” If the question crosses scales, run Product Judgement and get one prioritized sequence. Then decide. The Skill can surface options. It can’t own the call. ## Continue reading - [The Feature Works. The Product Doesn't.](https://www.kevincanlas.com/writings/the-feature-works-the-product-doesnt) — When AI makes the answer to “can we build it?” almost always yes, product judgment becomes the work that protects coherence. (7 min) - [Taste in the Age of AI](https://www.kevincanlas.com/writings/taste-in-the-age-of-ai) — AI can generate polished work faster than ever. Taste is still the judgment that decides what lands. (6 min) [All writings](https://www.kevincanlas.com/writings)