Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Product engineer a perfect technical executor for cross-functional teams by Artur Hebda

Artur is going to talk about the product-code relationship.
When is the code good? How to maintain tech debt?
What is the balance between business requirements and refactoring needs?
He will also talk about the Power of input, sharing some useful tips and best practices.

Artur has more than 8 years of experience in helping startups and mid-sized companies build great products. He has been working closely with specialists having diverse backgrounds. It allowed him to become a versatile Software Engineer with Product Management and UX perspectives.

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all
  • Be the first to comment

  • Be the first to like this

Product engineer a perfect technical executor for cross-functional teams by Artur Hebda

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

×