![\"\"](\"https:\/\/janbosch.com\/blog\/wp-content\/uploads\/2018\/09\/eye-3374462_1920.jpg\")
<\/p>\n<\/p>\n
(image credit: pixabay)<\/p>\n
Engineers form the core of a product company. Although I have the greatest respect for sales people and know how hard a job that can be, it\u2019s the engineers that design and develop the product that, in the end, is needed to have anything to sell.<\/p>\n
Building a product that sells of course requires that customers actually want it and are willing to pay for. Although this may seem obvious, this is where the problem starts in many companies. The process of figuring out what customers want as well as the process of monetizing the product, and the associated business model, tends to get split over multiple functions and roles in the organization. Among others, we have sales & marketing, product management, engineering and user experience\/usability experts. Each of these functions and roles owns part of the process of building and selling the product or service.<\/p>\n
In most companies that I work with, the responsibilities between the roles has resulted in engineers basically asking for requirements and declaring success when they\u2019ve delivered a solution that passes all test cases and satisfies the various edge cases that might exist. Although this attitude is considered to be the right one in most engineering cultures, it has several problems associated with it.<\/p>\n
The first problem is that many engineers build whatever feature they are asked to build in the same way: basically a solid implementation that covers all exceptional cases, minimizes interactions with other features and deals elegantly with those where necessary. In our research, however, we see that companies build at least four different types of features [1]. As shown in the figure below, we recognize duty, checkbox, wow and flow features. Each of these features requires a different implementation as well as a different level of coverage. A \u201cwow\u201d feature should show one use-case really well so that marketing and sales can use it, but doesn\u2019t have to cover all alternative use cases. A checkbox or duty feature should be built to just enough to satisfy the regulator or to allow the company to claim that they have feature parity with a competitor product. It\u2019s only \u201cflow\u201d features that require a full \u201cgold-plated\u201d realization and the best possible user experience. Engineers not understanding the difference between the categories of features tend to waste a significant amount of resources for the company.<\/p>\n
![\"\"](\"https:\/\/janbosch.com\/blog\/wp-content\/uploads\/2018\/09\/Screen-Shot-2018-09-07-at-09.22.53.png\")
<\/p>\n
Figure<\/strong>: Feature Types model [1]<\/p>\n The second challenge that engineers run into is picking items from the backlog that do not actually generate revenue for the company. In a company that I visited recently, engineers tended to focus on improving a mature product for which the customers paid a yearly maintenance fee. The company was also building new products to offer to existing and new customers, but the R&D organization throttled those efforts due to a claimed lack of resources. In practice, however, engineers tended to build features that did not generate any additional revenue for the company and ignored spending time on the new products that would generate additional revenue. This lack of understanding of the business that the company is in leads to significant lost revenue and opportunity cost.<\/p>\n The third challenge that I see several R&D teams end up in is a highly limited and distorted understanding of what customer success looks like. Especially when the agreed division of work is one where product management throws requirements and specifications over the wall and R&D teams just build to spec, the realization of functionality tends to leave a lot to be desired from the user perspective. Customer empathy is incredibly important when building a product that delivers on customer needs and expectations, but I still meet many teams that have not realized this yet.<\/p>\n Concluding, my dear, esteemed engineers, business is too important to leave to the business folks. You have to get involved and deeply understand what business we\u2019re in, how revenue is generated, what matters for customers and what sales needs to convince customers to go into business with us. You can\u2019t ignore this and think it\u2019s not your problem. Especially in a world that is changing ever faster, engineers need to be in tune with the market and act accordingly. It is your job, after all!<\/p>\n To get more insights earlier, sign up for my mailing list at\u00a0<\/em>jan@janbosch.com<\/em><\/a>\u00a0or follow me on<\/em> janbosch.com\/blog<\/em><\/a>, LinkedIn (<\/em>linkedin.com\/in\/janbosch<\/em><\/a>) or Twitter (<\/em>@JanBosch<\/em><\/a>).<\/em><\/p>\n","protected":false},"excerpt":{"rendered":" (image credit: pixabay) Engineers form the core of a product company. Although I have the greatest respect for sales people and know how hard a job that can be, it\u2019s the engineers that design and develop the product that, in the end, is needed to have anything to sell. Building a product that sells of … Read more<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"generate_page_header":"","footnotes":""},"categories":[8,10],"tags":[],"_links":{"self":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/583"}],"collection":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=583"}],"version-history":[{"count":4,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/583\/revisions"}],"predecessor-version":[{"id":589,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/583\/revisions\/589"}],"wp:attachment":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=583"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=583"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=583"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}[1] Fabijan, Aleksander, Helena Holmstr\u00f6m Olsson, and Jan Bosch. “Differentiating Feature Realization in Software Product Development.” International Conference on Product-Focused Software Process Improvement. Springer, Cham, 2017.<\/em><\/div>\n