Working Across Functions
Ishita designs a beautiful one-tap checkout with a sliding animation, and Rohan shows it to leadership as the plan for the next sale. The checkout team sees it two weeks later and discovers that the animation needs the checkout screen rebuilt natively: four weeks of work they don't have. Everyone did their own job well, one after another, and the result is still a problem.
The rule
Explore the problem together early; let each craft own its part.
A product team usually has three crafts working side by side:
| Craft | Owns | At Haat |
|---|---|---|
| Product | Why and what: the problem, priorities, success measures | Rohan |
| Design | The experience: flows, screens, how it feels to use | Ishita |
| Engineering | How: feasibility, approach, quality, running it | Meera and Farhan |
Each craft owns its own decisions. But the three have to explore the problem together, not pass it down a line. When engineers see a problem early, they spot cheaper routes and hidden constraints before anyone has promised anything. When designers hear the constraints early, they design within them.
Habits that keep the three together:
- Start from the problem, with data, not from a finished solution.
- Share goals and measures. All three chase "fewer people abandon checkout", not three separate to-do lists.
- Make trade-offs visible. "This design takes four weeks; this variant takes one and keeps most of the benefit." Then decide together, with product making the final call on priority.
- Review together along the way: a kickoff, design reviews that include engineers, and a regular demo for all three.
The same approach works with other functions, such as support, finance and legal: bring them in while their knowledge can still change the plan.
The shortcut
Before anyone commits to a solution, put all three crafts in one room with the problem, not the answer.
Start from the problem
Rohan shares the data: 18 per cent of shoppers abandon checkout at the payment step.
Drills
Answer fast — trust the rule.
When should engineers first get involved in a new feature?
Who owns the decision about which customer problem to tackle first?
Ishita's design would take four weeks; a variant takes one week and keeps most of the benefit. What should engineering do?
Which habit does most to prevent late surprises between product, design and engineering?
Remember
- Explore the problem together early; let each craft own its part.
- Put all three crafts in one room with the problem, not the answer.
- Make trade-offs visible, and let product make the final priority call with everyone informed.