[Asah 2026] Guest Speaker Session #3

Summary

The session explains how to move from discovering a genuine user problem to defining realistic technical requirements. Its central lesson is that a successful product is not necessarily the most sophisticated one: it is the one that addresses a real, validated need and fits the user’s circumstances.

1. Start with the problem, not the technology

• The speaker compares product development to tailoring clothes. A ready-made template may be convenient, but it may not fit a particular user’s needs.
• Teams can fall into the same trap by adopting whatever is fashionable—such as a chatbot or AI—before understanding the problem.
• This can create a “zombie app”: a technically impressive product that users do not adopt. A shopkeeper, for example, may prefer paper notes to a complicated inventory app.
• Common traps that lead to this outcome include:
  • Solution-first thinking: Jumping from a complaint straight to a feature or product.
  • Rushing discovery: Deciding what the problem is without exploring it sufficiently.
  • Feature bloat: Adding features to make a product seem impressive, even when they do not help users.

2. Discover users’ needs through research and observation

• Meet users to learn about their work and challenges—not simply to pitch a proposed solution.
• Keep conversations informal and respectful. A short interview of around 20 minutes may be enough for an initial conversation.
• Ask open-ended questions that invite people to explain their experiences. For example, “Can you show me how you record orders each day?” is more informative than a yes-or-no question.
• Observe users doing the work when possible. Watching a business during a busy period can reveal habits and obstacles people may not mention in an interview.
• Use language users understand rather than technical terms such as “backend” or “server.”
• AI tools can help with initial desk research, background reading, and organizing findings, but they do not replace talking to users or validating evidence.

The speaker offers a possible three-day structure for initial discovery:

1. Desk research: Learn about the domain and gather background information.
2. Field research: Talk with users and, when possible, observe their work.
3. Synthesis and confirmation: Analyze the findings, form conclusions, and check them with users.

3. Dig beneath complaints to find root causes

A complaint is a clue, not necessarily the underlying problem. The speaker recommends using Five Whys to investigate causes rather than immediately designing a solution.

For example:

1. Sales are low.
2. Customers often leave without buying.
3. The products they want are out of stock.
4. The shop owner does not know which stock is running low.
5. Stock is recorded manually and checked only when the shop closes.

The deeper cause—not merely “sales are low”—can point to a more useful opportunity for a solution.

4. Turn research into a validated problem statement

• Record important user quotes and insights. If recording interviews, ask permission first.
• Group related observations using an affinity diagram: cluster statements or quotes by theme, then look for patterns.
• Write insights that explain what a user does or experiences and why.
• Turn the insight into a problem statement that identifies:
  • Who is experiencing the problem.
  • What difficulty they face.
  • When or in what situation it occurs.
  • What impact it has, ideally supported by evidence or measurable details.
• Confirm the statement with users. If it does not reflect their actual experience, revise it.

For example, a shop owner may have difficulty monitoring popular items during busy periods, causing stockouts and lost sales.

5. Prioritize a manageable problem

When research surfaces several problems, select one that matters and can realistically be addressed.

• Compare problems by how often they occur, how harmful they are, and whether a useful solution can be built within the available time.
• Consider whether users are likely to adopt the proposed solution.
• The speaker suggests a short development cycle—around two weeks—as one way to keep work focused.
• Work on the highest-priority problems first; defer lower-priority items to later cycles. For a capstone project, solving one or two important problems may be stronger than building an oversized product.

6. Define the solution before writing technical requirements

Before implementation, align the team and stakeholders on the problem and the intended outcome.

• A job story describes a situation, what the user wants to do in that situation, and the result they want. For example: “When there are many buyers, I want to record outgoing items without stopping service so that stock records stay complete.”
• A user story expresses a need from the user’s perspective, commonly in the form: “As a [user], I want [to do something], so that [benefit].”
• A short product requirements document (PRD) can capture:
  • The problem and why it matters.
  • The user and their needs.
  • The proposed stories or requirements.
  • Priorities for the current development cycle.
  • How success will be measured.
  • The technical requirements needed to deliver the solution.
• Use measurable success criteria where possible, such as reducing missed stock entries.
• Make the PRD a shared reference for the team and update it as user feedback comes in.

7. Keep the solution proportionate

• Separate functional requirements—what the product must do—from non-functional requirements, such as usability, accessibility, or performance expectations.
• Use technology, including AI, only when it provides clear user value. AI might help analyze sales data or generate useful insights; it does not have to appear as a chatbot.
• If a conventional system solves the problem just as well, do not add AI only to satisfy a rubric or make the product seem advanced.
• When requirements are too complex, protect the solution’s core value and defer additional features. The speaker describes an MVP as the simplest usable version that preserves that value and can be tested with users.

8. Keep stakeholders involved

• The speaker recommends regular team updates, including daily stand-ups to share progress and blockers.
• For MSME solutions, observe the existing business process and speak with the people who perform different parts of it. Look for a specific gap that can be improved without unnecessarily disrupting established routines.

Main takeaway

Good product development begins with listening, investigation, and validation. Build around a well-evidenced user problem, then choose the simplest solution that delivers meaningful benefit. Technical sophistication is secondary to usefulness and adoption.

Speakers and sources featured

Speakers

• Lalu Triawanri Novianung, known as Aan, Head of Creative at Dicoding Indonesia and the guest speaker.
• Muhammad Kevin Aroimo, session moderator.

Frameworks, tools, and sources mentioned

• Five Whys analysis.
• Affinity diagrams.
• Job stories and user stories.
• Product requirements documents (PRDs) and MVPs.
• Daily stand-ups and development cycles.
• GPT and Gemini for research; Gemini Notebook for organizing research and creating mind maps.
• Intercom, mentioned in connection with a short document for aligning a team on a problem and solution.
• The speaker corrected an attribution during the talk: the quote about spending more time thinking about a problem than solving it was attributed to Abraham Lincoln, not Albert Einstein.