Tags
Writing, research, projects, and photos around “Product Thinking”.
The Business Model Canvas from an enterprise investment class, noted for myself: what each of the nine boxes is, the question each box must answer, and why the line 'all of them must be satisfied for a project to succeed' depends on the company's stage.
A note on a distinction: the business model canvas is 'made for yourself,' the startup pitch is 'told to others,' and investor due diligence is 'others scrutinizing you'; the three differ completely in purpose, focus, and framing — don't mix them up.
Good collaboration is built on trust, shared information, and solving problems together; when goals conflict, don't make promises privately—escalate with complete information to align.
Technology can't manufacture a selling point out of thin air, but engineers can still help the team understand users more precisely, shorten validation cycles, and turn implicit constraints into choosable problems.
When entering an unfamiliar business or system, don't rush to start from a local solution. First map the users, the process, inputs and outputs, key constraints, and value, so you know what to ask.
Product sense isn't guessing at requirements. A ready-to-use list of talking points, from two angles: how engineers should understand the product, and what product managers actually do.
Part of the column “One-on-One Conversations” · Chapter 6
From completing requirements to taking part in planning, how engineers place technical implementation between user problems and business outcomes.
Part of the column “Product Judgment” · Chapter 1
The job of a product overview is not to collect as many facts as possible, but to help readers build a shared question, form judgments, and understand what evidence is still missing within a limited time.
Part of the column “Product Judgment” · Chapter 2
Self-use isn't about 'spending more time in the product'; it's a feedback system spanning real tasks, valid evidence, and verified fixes.