How the Product Team Works
How Product and Engineering turn customer signals into clear decisions, focused priorities, and measurable outcomes.
Product at Hardal is not a request desk between customers and Engineering. Its job is to turn signals into clear decisions and measurable outcomes.
Our operating loop is:
Signal → evidence → priority → execution → launch → learning
The process is intentionally lightweight. It should make ownership, priorities, trade-offs, and outcomes visible without creating a second job made of meetings and status reporting.
This page explains who owns each part of that process and how Product and Engineering work together. How Product Work Moves explains the workflow from intake to learning.
What Product owns
Product is responsible for connecting four kinds of context:
- what customers are experiencing,
- how people use the product,
- what matters commercially,
- what is technically possible and responsible.
The Product Manager turns this context into a clear problem, a priority recommendation, a desired outcome, and a way to evaluate success.
Product does not decide the technical solution alone. It makes sure the team is solving the right problem for the right reason.
Our working principles
Start with the problem. "Customers cannot understand where their data comes from" is a problem. "Add another dashboard tab" is one possible solution.
Use evidence. Customer conversations, support patterns, product usage, commercial context, and technical findings are stronger than personal preference.
Make ownership visible. Every active item should have someone responsible for its next decision or action.
Keep priorities focused. Adding work has a cost. A new commitment should replace, reduce, or delay something else.
Write decisions down. Important decisions, blockers, and changes in direction should be understandable without a meeting.
Communicate publicly by default. Product context should not live in private messages or in one person's memory.
Follow meaningful work after launch. Shipping is not the same as succeeding. Important launches need a success signal, a follow-up owner, and a review date.
Use the smallest process that solves the problem. Process should reduce confusion, not create ceremony.
Decision ownership
| Area | Decision owner |
|---|---|
| Problem definition, evidence, priority recommendation, desired outcome, and success signal | Product Manager |
| Technical approach, architecture, implementation, and engineering quality | Lead Developer |
| Cycle capacity, scope trade-offs, work-in-progress exceptions, and testing handoff | Product Manager and Lead Developer together |
| Company direction or major commercial, security, privacy, or compliance risk | Founders |
Product owns what problem and outcome matter. Engineering owns how the solution is built safely.
The decision owner is accountable for getting the decision made. This does not mean deciding alone. The owner gathers the necessary evidence and input, records the reasoning, and makes the next action clear.
How Product and Engineering work together
Product and Engineering collaborate from the beginning of a problem, not after a solution has already been designed.
Product brings:
- customer and market context,
- product evidence,
- the intended outcome,
- priority and timing,
- success criteria.
Engineering brings:
- technical constraints and opportunities,
- architecture and implementation options,
- effort and dependency context,
- security, privacy, performance, and reliability considerations,
- testing and release requirements.
Both sides are expected to challenge assumptions. Product can question whether a technically simple solution solves the customer problem. Engineering can question whether a requested outcome is worth its complexity or risk.
The goal is not to protect role boundaries. The goal is to make a better decision.
How we think about priorities
Not every customer request becomes a feature. Not every bug has the same impact. Not every internal idea deserves immediate execution.
We consider:
- how many customers or users are affected,
- the severity and frequency of the problem,
- product usage and behavioral evidence,
- revenue, retention, or strategic importance,
- technical risk and dependencies,
- the cost of delaying the decision,
- the opportunity cost of choosing it.
A score or template can support this discussion, but it does not make the decision for us. Product recommends the priority and explains the evidence. Product and Engineering then align on what can be credibly executed.
The documents behind the process
Our internal Product workspace contains four documents:
- Product — Start Here
- Intake, Triage & Definition of Ready
- Cycle, In Progress & Execution
- Done, Product Updates & Learning
These documents contain the detailed working standards used by the team.
The Handbook explains the durable model publicly. The internal documents contain operational detail that changes more frequently.
We maintain one canonical version of each rule. We do not keep competing workflows in different documents or tools.
Where communication belongs
Different information belongs in different places:
- Linear: Work, ownership, priorities, dependencies, decisions, and status
- Slack: Public discussion, questions, short-lived coordination, and Product Updates
- Shared Drive: Analysis, working documents, and records
- GitHub: Code review and code-related technical discussion
- Handbook: Durable company-wide principles
We communicate asynchronously by default and protect focus time, including no-meeting Mondays.
A real blocker or urgent risk should still be raised immediately in writing. Async-first does not mean waiting quietly.
How we share progress
Product publishes a concise update each week:
- What we heard: Important customer, product, commercial, or technical signals
- What we decided: Decisions and the short rationale
- What changed: Shipped, rescoped, deferred, cancelled, or delayed work
- What we are watching: Metrics, launches, risks, blockers, and open questions
- Where input is needed: The person, exact question, and response date
The update is a summary of decisions and outcomes, not a list of completed tasks.
The goal is that someone returning from time off can understand what changed without needing a status meeting.
What this model protects
This way of working protects the team from:
- building solutions before understanding the problem,
- treating every request as an immediate commitment,
- starting more work than we can finish,
- hiding decisions in meetings or private messages,
- confusing a planning cycle with a release deadline,
- calling work successful only because it shipped.
A healthy Product team does more than keep work moving. It keeps the relationship between evidence, decisions, delivery, and outcomes visible.