Artur Hebda: Product Engineer - a perfect technical executor for cross-functional teams

Presentation by Artur Hebda at Lviv RUG #Pivorak conference.

"Product Engineer - a perfect technical executor for cross-functional teams"
- When is the code good?
- How to maintain tech debt?
- What is the balance between business requirements and refactoring needs?

With Ruby on Rails as one of Railsware core areas of expertise and with most innovative and efficient approaches to building great products, we were very enthusiastic about supporting the Pivorak community which shares our values.

Transcript

1. Product Engineer - a perfect technical executor for cross-functional teams Artur Hebda Railsware Labs
2. Product Engineer - a perfect technical executor for cross-functionalproduct teams Artur Hebda Railsware Labs
4. We like to build things.
5. We build client and own products.
6. We build client and own products. Consultancy
7. We build client and own products. Consultancy Labs
8. We build client and own products. Consultancy Labs
9. We don’t do what client wants. We do what client needs.
10. 5 years ago...
16. We build the wrong thing.
17. Wrong things do not withstand the test of time.
18. How many of products you’ve worked on still help people?
19. 40% gone
20. 3.5 years gone
21. A lot of companies fail.
22. 80% startups in 18 months
23. 50% in 5 years
24. 70% in 10 years
28. Reason #1 : No market need.
29. Reason #1 : No market need anymore.
30. Reason #1 : No market need yet.
31. Netflix disrupted market by providing better experience.
32. People use products that make their lives better.
33. Why do you prefer one messaging app over another? Clean code?
34. Code is just one facet of building products.
35. Product success depends on solving user problems.
36. Users pay for the value product delivers to them.
37. Solving problems of users increases product value.
38. Shipping goods...
39. Video: https://goo.gl/XNyDRw Source: https://goo.gl/XrSCbQ
41. Source: https://goo.gl/XrSCbQ
43. Products are built for people.
44. Planning a meeting...
45. Source : https://tootallfritz.wordpress.com
48. All problems seem pressing… but they are not.
49. Prefer careful planning over sense of urgency.
50. What user problem does the story help to solve?
51. Is it what user needs?
52. Pick highest-value user problems.
53. Do you find it difficult to keep entire problem or solution in your head?
54. Source : https://m.signalvnoise.com/running-in-circles-aae73d79ce19
55. Skye Bridge, Scotland
56. Implan = #issue and #idea
57. Implan = #issue and #idea Implan = #benefit Implan = #risk
59. #issue #issue #issue #issue #idea #idea #issue #idea #idea #idea #idea #benefit #benefit #benefit #risk
60. Implan helps to understand problem space.
61. Implan helps to explore solution space.
62. Implan helps to make informed decisions.
63. “I would like to know about user as much as I can. It helps to set priorities that impact my decisions. Yuriy Marchenko, Railsware
64. Planning makes things faster.
65. 3 years ago...
70. Tha y , Zep !
71. “We either make ourselves miserable, or we make ourselves strong. The amount of work is the same. Carlos Castaneda
72. Problems of “silo” approach
73. Source : http://projectcartoon.com
74. Do you think it’s not your job?
75. Roles are just labels to group functions, like modules.
76. Engineer = {implement, engineer, architect, lead, bend}
77. “In real projects, even in large organizations, it’s really difficult to limit oneself to own specialty. Jan Stypka, Spotify
78. Feasible? Desirable? Viable? ENGINEERING DESIGN PRODUCT MANAGEMENT Successful Product
80. Product Engineer closes the gap between tech and product.
81. It’s not about doing someone else’s job, it’s about moving forward as a team.
82. Growing tomatoes...
84. Source: ABC13 Houston
85. Poor communication leads to frustration, missed chances and worse outcomes.
86. Make tech debt transparent Source: http://stocksmasters.com
87. Would you like to contribute to the product you work on?
89. Customer Feedback Product Team Stakeholders INPUT = single source of truth
90. Customer Feedback Product Team Stakeholders INPUT = single source of truth Context #1 Context #2 Context #3
91. Customer Feedback Product Team Stakeholders INPUT = single source of truth Context #1 Context #2 Context #3 Context #1/2 Context #1/1
92. 2 projects JIRA projects across entire Railsware : Input and Roadmap
93. 3 years Time we spent using and improving Input as an approach
94. 4500+ Created inputs
95. 825 Components = contexts
96. Input stimulates contributions and feeling of being heard.
97. In short...
98. We like to build things.
99. We like to build things right.
100. Let’s build the right things.
101. 80_000
102. 63_400
103. Thank you! Questions? Feedback: arturhebda.com
104. Thank you! Questions? Feedback: arturhebda.com
105. Thank you! Questions? Feedback: arturhebda.com