About Nick

Hi, I am Jialuo Mu, Nick, a Product Maker.

My background is fairly mixed. I studied information management, finance, and human-computer interaction across my undergraduate and graduate education; in practice, I have also worked across marketing, product management, and user experience. These broad attempts gradually shaped a more composite way of working: standing at the intersection of PM, UX, Design Engineer, and GTM, and trying to understand a problem through users, business, design, and technology at the same time.

I am not too attached to a single job label. I care more about two broader goals:

• How to use AI to reduce translation loss between market, product, design, and engineering, so a good idea can move more quickly into a perceivable, testable, and iterable state.
• How to rethink AI-native products: when Agents become part of the experience, rather than just a feature embedded in the interface, how should we design new interactions, workflows, and ways of forming product judgment?

If you are also thinking about new AI product forms, how Agent workflows can improve the efficiency of traditional teams, or if you are interested in my background, feel free to reach out: [email protected], Xiaohongshu, LinkedIn, X.com.

Resume attachment

Product Maker in the AI Era

One important reason companies exist is to reduce external transaction costs: when the transaction costs of external collaboration are too high, companies internalize those collaborations inside the organization (Ronald Coase, "The Nature of the Firm," 1937). But in traditional software engineering, internal organizations also produce new costs: communication, collaboration, handoffs, scheduling, and repeated alignment. The larger the team, the more visible these frictions tend to become. The Mythical Man-Month discusses a similar problem: what often slows things down is not the technology itself, but the coordination cost that accumulates inside organizations.

What AI truly changes is not only production efficiency, but also the boundaries between roles and the concept of a team itself. In the past, many things required PM, design, GTM, and other roles to circulate repeatedly. In many early explorations and prototype stages, those loops can now converge into smaller and faster personal loops.

This is why I position myself as a Product Maker. Compared with only doing market research, product design, UX prototypes, or requirement documents, I care more about "solving the problem" itself: can I reduce translation loss, compress market insight, user needs, product design, and prototype experiments into one low-friction chain; can I use AI, design, and code to push a vague idea more quickly into a state that is perceivable, testable, and discussable?

The value of a Product Maker is not just finishing tasks faster. It is forming judgment faster, and turning that judgment into verifiable value faster. I understand this role shift as follows: judgment, design, and implementation that were originally scattered across multiple positions are being recompressed into smaller personal loops.

Diagram reference: @goocarlos

The New Benchmark

In the AI era, the cost of a single task is dropping quickly. What becomes truly scarce is no longer just "whether you can do it," but "whether you can find what is worth doing faster and validate it." So what I value is not how fast a single task gets completed, but two higher-level flywheels:

Source: designcouncil

• Time to Insight: the speed from observation, understanding, and experimentation to judgment.
• Time to Value: the speed from judgment to real value output and continued validation.

This means good product engineering is not only about speeding up old workflows. It is about making these two flywheels spin faster. The value of design and research is not only producing solutions or reports, but helping us abstract needs and form judgment faster, then pushing those judgments into verifiable product evolution.

It also means product judgment cannot rely entirely on second-hand information that has been translated layer by layer. User feedback, market signals, experiment results, and technical constraints all matter, but ideally they should be rapidly absorbed, recombined, and validated inside the same high-density cognitive loop, rather than gradually losing fidelity across an overly long collaboration chain.

Today, AI expands the radius of the individual loop. From user research, prototype planning, and interface interaction to technical validation, everything can happen continuously inside the same high-throughput, low-internal-friction workflow. Therefore, my practice is not just "using AI to move faster." It is organized around a new product work system that accelerates the insight flywheel and the value flywheel separately, while allowing the two to feed each other.

This work system mainly lands in two directions: one is reorganizing and optimizing existing workflows; the other is continuously exploring AI-native product forms.

My Product Work System

I am more used to understanding product work as two flywheels that can keep accelerating, rather than as a linear division-of-labor chain. The core carrier of this system is the repo convention I am practicing: EDF 2.0. The fuller work system page now lives at work-system.

EDF stands for Executable Design File. It is not another PRD template, and it is not simply a Design-to-Code tool. It is a work system that puts product judgment, business logic, data contracts, interface expression, code implementation, and validation mechanisms into the same repo. The goal behind the name is to make design files no longer just static deliverables, but executable product assets that Agents can read, call, modify, validate, and ultimately use to push implementation forward.

Turning Product Context into a Single Source of Truth

In traditional workflows, insight, definition, design, development, and validation are often scattered across different roles, documents, and tools. Information is repeatedly translated as it flows, and judgment is easily diluted during handoff. EDF 2.0 tries to solve exactly this problem: product context should not only stay in meetings, chat logs, or design files. It should be deposited into a single source of truth (SSOT) that both Agents and humans can repeatedly read, review, and update.

It compresses product work into two interlocking flywheels: one is responsible for forming judgment faster, and the other pushes judgment toward verifiable value faster.

Concept structure:

Time to Insight Flywheel
Signal / Why -> Judgment / What
Users, markets, experiments, and technical signals -> problem definitions, state transitions, product hypotheses

             -> pushes

Time to Value Flywheel
Interface -> Prototype / Src -> Feedback / Test
Interface expression -> runnable implementation -> usage feedback, automated validation, cross-layer checks

             -> feeds back

New feedback and experiment results return to the Time to Insight flywheel

Making Product Content Operable by Agents

So the goal of EDF 2.0 is not to let AI simply participate in one step. It is to turn different forms of product work into objects that AI Coding Agents can read, call, modify, and validate: documents, state machines, design files, API contracts, code, and tests should no longer be isolated outputs. They should become contextual material within the same work system.

More importantly, it tries to transform content that used to be scattered across different tools, formats, and roles into a mutually compatible context window that can be continuously compressed and rebuilt. In this way, product judgment, interface expression, technical implementation, and feedback validation can iterate quickly in the same context, instead of requiring fresh explanation, fresh handoff, and fresh alignment at every step.

Two Practice Directions

Based on this goal, my practice mainly splits into two directions: one optimizes existing workflows and reduces context loss between design, product, development, and GTM; the other explores AI-native product forms and asks how products should be redesigned when the Agent itself becomes part of the user experience.

1. Optimizing Existing Workflows

The first type of practice uses EDF 2.0 to reorganize existing workflows. The point is not to automate one isolated step, but to reduce repeated translation loss between product, design, development, and GTM. In traditional collaboration, an idea often goes through many format conversions: user feedback is organized into requirements, requirements become a PRD, the PRD is translated into design files, design files are translated into code, and after launch, feedback returns to documents and meetings. Each conversion loses part of the context and makes the original judgment increasingly indirect. Here, EDF 2.0 is more like a product work convention living inside a Git repo: it puts different forms of content into the same context, so Agents can read, transform, align, and validate them.

Workflow structure:

Different entry points
User feedback / GTM copy / design drafts / code prototypes / market observations
      ->
Enter EDF 2.0 Context
Why / What / Interface / Src / Test
      ->
Agent operations
Read, transform, complete, extract, validate
      ->
Runnable artifacts
Pages, prototypes, APIs, tests, documents
      ->
Guardrails
Preview, tests, diff, human review
      ->
Back to EDF 2.0 Context

Here I mainly focus on three working principles. They are not separate features, but different answers to the same question: how can different forms of product content enter, be recovered into, and be continuously validated inside the same context?

1. Any-Point Entry
   Solves the question of "where to start." Visually strong problems can enter from Interface, logic-heavy problems can enter from What, problems that already have prototypes can enter from Src, and market/user problems can enter from Why.

2. Reverse Extraction
   Solves the question of "how to deposit things back." When a prototype or page is already running, Agents can reverse-extract state transitions, API contracts, design constraints, and edge cases from existing code, interface, and interaction, turning one-off implementation back into reusable product assets.

3. Guardrails
   Solves the question of "how to avoid drifting." Through tests, contract validation, cross-layer diffs, and human review, the system continuously checks whether code implementation, interface states, and the original product judgment have drifted away from each other. AI can generate and rewrite quickly, but it needs to be constrained by explicit product context.

Examples

A typical example is Design to Front-end Dev. In the past, moving from design files to frontend code usually required a lot of verbal explanation, annotation, component alignment, and rework. In the EDF 2.0 approach, the design surface is not only an image for humans to look at, but a readable and writable material containing layout, state, component semantics, and interaction intent. Agents can read this material, combine it with components, API contracts, and implementation constraints inside the repo, and generate frontend implementation that is closer to the real codebase.

Need to add concrete examples. Pay attention to granularity. Mention what the Agent used and what tools/software were involved. Do not make this purely theoretical. [IMPORTANT] Design to Front-end Dev (paper / specs api (spec-based dev?) <-> coding agent + repo <-> front-end code)

Another example is reverse iteration from GTM to Product Design. Many market signals, user language, and positioning experiments originally stay only in documents, emails, or published content, but they actually contain judgments about user needs and product value. Through EDF 2.0, these signals can return to the Why and What layers and continue influencing information architecture, interface expression, feature priority, and experiment direction.

Need one or two concrete cases here. The goal is to explain clearly how, based on EDF 2.0, context loss and repeated translation between different functions are reduced. [IMPORTANT]

So the goal of optimizing existing workflows is not to remove humans from the process. It is to split product evolution into two flywheels that can spin faster: one accelerates Time to Insight, forming judgment faster from market, user, experiment, and technology changes; the other accelerates Time to Value, pushing judgment faster into runnable, verifiable, and iterable product outcomes.

The essence of design and research is to abstract needs and push product evolution. But when some evolution can happen faster through A/B tests, flip experiments, rapid prototypes, or real usage feedback, design and research do not always need to remain long upfront processes. They can become high-frequency inputs into the two flywheels. My task is to reduce translation loss as much as possible, so the speed of insight and value loops can improve by orders of magnitude.

You can visit the nickmu.com homepage or Playground to see how these methods land in specific content and interfaces.

• What should go here?

2. Exploring AI-Native Products

The second type of practice explores products that are not simply "old products with an AI feature added," but product forms regenerated from model capabilities, Agent behavior, and human-AI collaboration.

This direction leans more toward Time to Insight: through rapid prototypes and experiments, I try to understand the boundaries, interaction patterns, and real value of AI-native products.

Representative projects:

• edf 3.0

Taste is a subtle art.

When AI dramatically lowers execution cost and efficiency becomes the baseline, what becomes truly scarce is judgment and taste. Because when most people can produce interfaces, copy, code, and plans faster, difference no longer comes only from "whether you can do it," but from "knowing what is worth doing, to what degree, and with what quality of expression."

My understanding of craftsmanship is not just visual polish. It is continuous attention to information density, interaction rhythm, state feedback, edge handling, and the overall character of a product. AI can amplify output, but whether a product is ultimately worth using still depends on these subtle but crucial judgments.

What I Am Paying Attention To

Next, I will keep focusing on three questions:

• proactive agent and meta agent
• agent parts: memory + context engineering
• two types of agentic systems: for most scenarios, there will be one general-purpose agent, and for some edge cases, specifically designed agents will appear.

1. How Agents become real execution hubs: not just answering questions, but taking over parts of context, state, and task progress.
2. What AI-native products will become: when models become part of the product, how will interfaces, workflows, and user roles change?
3. How individual leverage gets redefined: when middle layers keep collapsing, how can one person organize information, tools, and judgment to create value that previously required a team?

Contact

[email protected]

Xiaohongshu

LinkedIn

X.com

If you are thinking about AI products, Agent workflows, or similar questions, I would be happy to connect.