The document discusses the importance of building products that meet customer needs rather than focusing solely on code quality. It emphasizes the need for developers to understand the market and user expectations, advocating for early releases and feedback to ensure product relevance. Key takeaways include knowing the domain, releasing early, and continuously improving based on user input.

1. The only thing that matters
And it’s not code quality

2. Imagine the following situation

3. Product: Hey John, please take a look
at user story #714

4. Developer: Sure

5. User story #714:
“Japanese Hedge funds want to know about
every transaction of more than $10M against
their local currency. Therefore, we’ll send an
email alert every time such a transaction
happens”

6. User story #714:
“Japanese Hedge funds want to know about
every transaction of more than $10M against
their local currency. Therefore, we’ll send an
email alert every time such a transaction
happens”

7. Developer: Cool, I’m on it

8. Product: Thanks buddy

9. Our developer, John, is working, and
produce the following code:

10. if (transaction.currencyA === ‘YEN’ &&
transaction.usdEquivAmount >= 1e7)
{
// send email alert
}

11. if (transaction.currencyA === ‘YEN’ &&
transaction.usdEquivAmount >= 1e7)
{
// send email alert
}

12. if (transaction.currencyA === ‘YEN’ &&
transaction.usdEquivAmount >= 1e7)
{
// send email alert
}

13. if (transaction.currencyA === ‘YEN’ &&
transaction.usdEquivAmount >= 1e7)
{
// send email alert
}

14. if (transaction.currencyA === ‘YEN’ &&
transaction.usdEquivAmount >= 1e7)
{
// send email alert
}

15. if (transaction.currencyA === ‘YEN’ &&
transaction.usdEquivAmount >= 1e7)
{
// send email alert
}
Do you see anything wrong with this code?
We will get back to it later.

16. The only thing that matters
And it’s not code quality building the right thing

17. Hi, my name is Adir Amsalem,
I like to build things,
And I think most of you
evaluate your work by the
wrong metrics.

18. Agenda:
1. The tale of a product feature
2. How our work is evaluated
3. How we can bridge the gap
4. What’s next

19. Agenda:
1. The tale of a product feature
2. How our work is evaluated
3. How we can bridge the gap
4. What’s next

20. Product features come from 2 sources:
1. Product Manager ideas
2. Customer requests

21. Let’s see how it happens

22. Product Manager ideas:
1. Think about something in shower
2. Make sure it’s beneficial for customers
3. Make sure it supports company goals
4. Add it to roadmap

23. Customer requests:
1. Customer complain: “%@&^%$#@!#$”
2. Put yourself in customer position
3. Understand the case and transform
“want” to “need” (a.k.a “faster horses”)
4. Repeat steps 2-4 from previous slide

24. Great, let’s continue

25. Agenda:
1. The tale of a product feature
2. How our work is evaluated
3. How we can bridge the gap
4. What’s next

26. Who’s evaluating or interacting with our
work:
1. Future us and other developers
2. Customers

27. What might come up?

28. How developers evaluate our work:
1. Is this readable?
2. Is this flexible?
3. Is this scalable?
4. Is this testable?
5. Is this simple?

29. How customers evaluate our work:
1. Is this useful?
2. Is this makes me feel good?

30. Developers
1. Is this readable?
2. Is this flexible?
3. Is this scalable?
4. Is this testable?
5. Is this simple?
Customers
1. Is this useful?
2. Is this makes me feel good?
Do you see any difference similarity?

31. We’ve been developing products for
years, and we evaluate our work
completely different from our
customers

32. Now, you might step up and say:

33. But hey!
I’m just a developer.
That’s the Product Manager role.

34. So...

35. 1. You’re not “just a developer”

36. 2. That’s your role as well

37. There is no “my role” and “their role”.
There is “our role”.
And our role is to build a kickass
product.

38. So let’s do it

39. Agenda:
1. The tale of a product feature
2. How our work is evaluated
3. How we can bridge the gap
4. What’s next

40. “Usually, the riskiest aspect of new
products is not technology (whether it
can be built) but market (will people use
it and pay for it)”

41. Doing the right thing is only
possible by releasing
features early and receive
feedback from users.
“Building something nobody
wants is the #1 company
killer"

42. First-mover advantage is
the advantage gained by
the initial (“first-moving”)
significant occupant of a
market segment.
“If you're not embarrassed by
the first version of your product,
you've launched too late"

43. Work estimation of 12
months is ridiculous, it
never ends as planned.
You don’t need to release
everything at once.
Release small chunks by
splitting work to phases.

45. Nobody cares that you
work on your product for
over a year and you’ve
already coded 90% of it.
For your customers, 90% of
nothing is still nothing.

46. But most importantly...

47. Know your domain

48. Knowledge is the key to success

49. Remember the code from the
beginning?

50. if (transaction.currencyA === ‘YEN’ &&
transaction.usdEquivAmount >= 1e7)
{
// send email alert
}

51. if (transaction.currencyA === ‘YEN’ &&
transaction.usdEquivAmount >= 1e7)
{
// send email alert
}
The problem here is easily recognized by
anyone with knowledge in financial systems.

52. Let’s review it again

53. User story #714:
“Japanese Hedge funds want to know about
every transaction of more than $10M against
their local currency. Therefore, we’ll send an
email alert every time such a transaction
happens”

54. if (transaction.currencyA === ‘YEN’ &&
transaction.usdEquivAmount >= 1e7)
{
// send email alert
}
Anyone?

55. if (transaction.currencyA === ‘YEN’ &&
transaction.usdEquivAmount >= 1e7)
{
// send email alert
}

56. if (transaction.currencyA === ‘JPY’ &&
transaction.usdEquivAmount >= 1e7)
{
// send email alert
}

57. if (transaction.currencyA === ‘JPY’ &&
transaction.usdEquivAmount >= 1e7)
{
// send email alert
}

58. If John understood what he was doing,
instead of just coding what he has
been asked to, this mistake would not
happen

59. Be smart. Know your domain.

60. Agenda:
1. The tale of a product feature
2. How our work is evaluated
3. How we can bridge the gap
4. What’s next

61. Curious what else you can do?

62. 1. Take a look at your competitors

63. 2. Participate in product discussions

64. 3. Come up with ideas & suggestions

65. 4. Use your product

66. The possibilities are endless

67. But what about all the engineering
qualities...
Am I saying they’re not important?

68. But what about all the engineering
qualities...
Am I saying they’re not important?
NO! They’re super important.

69. As long as you build the right thing

70. Agenda:
1. The tale of a product feature
2. How our work is evaluated
3. How we can bridge the gap
4. What’s next

71. Takeaways #1
1. Release early
2. Make something people want
3. Make it work, then make it better
4. Dream in years, plan in months, ship in
days
5. It’s not done until it ships

72. Takeaways #2
1. Know your domain, knowledge is the key
to success
2. Take a look at your competitors
3. Participate in product discussions
4. Come up with ideas & suggestions
5. Use your product

73. Build the right thing

74. Thank you!
Share this with your friends
if you find this useful.