Business Reasoning for Rapid Productization in Small Enterprises ()
SMEs are often associated with a country’s higher economic growth [3,4]. Reference [5] studied the relationship between the size of the SME sector and economic growth in 45 countries. They found that the share of SME employment in total manufacturing employment is associated with a higher rate of gross domestic product (GDP) per capita growth. Reference [6] analysed the relationship between the relative size of the SME sector to total employment in manufacturing and GDP across 76 countries. By presenting comprehensive statistics utilising a cut-off of 250 employees, they showed that on average in these countries, the SMEs’ contribution to the labour force constitutes 54% of the economy. The impact of SMEs on employment is therefore globally significant.
On one hand, SMEs are an important and integral part of every country’s economy, the fastest growing sector of many economies, more flexible and adaptable in terms of structure, and having a faster speed of response than larger organizations [7]. In particular, the existence of a large SME sector does not directly cause economic growth but should be considered as one characteristic of a successful economy. On the other hand, SMEs typically have fewer financial resources, lower technical expertise and more limited management skills than large companies [8]. These limitations affect decision making related to product development and productization in the broader sense. In our study, we use the European definition. Within the SME category, the European Union (EU) defines medium-sized firms as having 50 - 249 employees, small firms as having 10 - 49 employees, and micro-firms as having 1 - 9 employees [9].
Innovation plays a key role in the long-term success for many companies. Customer-oriented companies are constantly challenged by the markets to keep their offering timely and responsive to the customer needs [10]. Respectively, new service and new product development have widely studied disciplines in academic research during the last three decades [11,12].
In many businesses, the final offering (with configurable products) is agreed in sales negotiations with the customer. Usually the product is created with a sales configuration tool or is bundled from a predefined set of components [13]. Obviously in many cases, a sales negotiation can lead to a situation where the customer’s demands cannot be fulfilled. This usually ends the sales negotiations and the customer leaves without a deal. According to [14], RP refers to those practices necessary to rapidly generate a manageable and exchangeable service offering. Little research has been carried out in the rapid response to customer requirements during the sales contact by complementing or altering the offering. Many managers and practitioners in SMEs have indicated that this kind of “rapid productization” is a common but informal and disorganized process in practice [15-17]. In addition, better management of the RP process would be beneficial [16].
Building a proper business case is the key to successful decision making related to RP [18]. Multiple methods are offered for the analysis of the business case in traditional product development; however, many of the proposed tools are too complex to be effectively used in a sales situation where decision making needs to be fast. Reference [18] stated that a business case is for analysing ideas that come through a company’s new product development (NPD) process to commit NPD resources to the right projects. The actions for building the traditional business case often include analysis of user needs, competitive analysis, market analysis, technical assessment, concept testing, financial/business analysis and action plans [2]. Reviewing the details of user needs and analysis (including, e.g., in-depth market research) would take too much time in the sales negotiations and in the time frame available for RP, which requires more flexible and agile methods for business analysis. Moreover, a proper business case to justify an investment should include a business and economic rationale for the investment, a definition of the investment and its feasibility, a financial model quantifying and valuing the benefits and costs of the investment, and a plan for delivering business and financial value [19]. It is not clear how these goals can be met in the sales situation as is often necessary for RP.
The first signal for the potential need for RP comes from the customer, typically during a sales situation when the existing product portfolio does not fully meet the customer needs. The aim of this study is to define business reasoning for RP and to provide practical guidelines for managers of small business. The research problem of this study can be addressed to following research questions:
RQ1: What are the business case objectives to start RP?
RQ2: What are the RP challenges of companies?
RQ3: What is the reasoning for RP?
The concept for productization used in this study has been aligned from the case companies and provides a frame for analysis. Cases are described in detail using a framework for structuring empirical data. Our research questions evolved from the practical challenges faced by both the case company and the industry in general are considered to be relevant for any organization interested in RP.
2. Methods
This retrospective case study uses a holistic research strategy [20,21]. We divided the research process into three phases: case study design, single-case data collection, and analysis and cross-case analysis (Figure 1).
Qualitative research refers to any type of research that produces findings that are not results of statistical or other means of quantification [22]. However, multiple data collection techniques can be employed in case studies and are likely to be used in combination with one another [20]. At the data collection phase, qualitative techniques may include focus groups, individual depth interviews, and case studies [23]. During analyses, the qualitative researcher often uses the content analysis of written or recorded materials. Qualitative research aims at providing an in-depth understanding about the situation in hand [23].
The data was drawn from semi-structured interviews designed to gather information about the upstream supply chain in rapid productization in US industries. Interviews were constructed to allow the interviewees to explain and clarify the case and topics as entities. Interviews were conducted in seven heterogeneous companies to obtain a wider view on the subject studied (Table 1). These companies were able to provide comprehensive study material and the extent of the phenomenon of RP.
The companies’ advanced practices and advanced product development processes can be used to compare other participating companies. The topics that were company
Figure 1. The research process.
Table 1. Case company characteristics.
specific are not reported. Altogether, the study included 11 interviews (Table 1). The interviewed industry experts were carefully selected based on their professional background and expertise. The selected participants hold positions related to productization. Their experience and current interest ensured high motivation and relevant knowledge about the topics discussed. The questionnaire was sent early enough to enable the interviewees to review it in advance. The interviews were recorded and transcribed and lasted up to 2 hours each.
NVivo®, QSR International Pty Ltd., Australia made software was used in organizing and analysing the interview content and for criteria categorization. For each company, we conducted a within-case analysis and classified the cases according to the following categories: RP, business case for RP, and RP challenges. Company characteristics are presented in Table 1.
3. Results
The study was carried out in a case study that incorporated electronics manufacturing to biotechnology SME companies located in North America. In the case companies, a number of employees vary from 7 to 37. The companies are referred to as A, B, C, D, E, F and G (Table 1).
Rapid Productization, Business Case Objectives and Challenges for RP
Company A, an electronics manufacturing company located in Washington aims to minimise interference with the standard product by using the same housing, plugs, or connectors. The benefit is that the company can optimise its ability to buy parts in volume, although perhaps at a lower volume, based on the business case. The project manager plays a key role during the RP process and is very involved throughout the process rather than a commodity salesperson that looks for a customer, takes an order, and moves on. RP also requires a more involved sales and purchase integration process. The drawback is the company needs to have more people internally, which would then change its structure from being “lean and mean”.
In Company A, the basic business purpose is to make a profit. The company makes money by making products and thus do not sell engineering time. Business reasoning for RP are to build a product that will sell and either make a large profit or potentially develop a new market. The justification for building a new design is to be a stepping stone to something else. If the customer preferences can be met, the company can justify a marginal fiscal performance on their first orders because they assume it will attract future customers, which could then place the company in a new market or give the company something new to develop in the long term. Company A is always looking for something new.
When using RP, Company A tries to find a product that fits a wider market. RP cannot be used to build a totally new product. As an example, total product development time for a tactical communications product ranges from 12 months to 14 months. One version of the product range is the way the company can make the best profit. If there is a need to make 14 versions of the product and to sell it to 14 different clients, there are risks that the package or features will not be set correctly. If use of RP requires third-party vendors, it is essential to know the person the company is going to deal with. From an interview with a purchase manager about the CEO’s response to possible vendor use: “Oh, I don’t want to use that vendor because they will be a risk for us. Can’t you use anybody else?”
Company B is a software solutions and equipment manufacturer located in California. A need for RP with a request to change the product roadmap pops up regularly when the research and development (R&D) section is working on a new product development case. One reason why there are so many new requirements coming from customers is that Company B is in a relatively early developmental stage. The product roadmap released to the market may have a reduced functional subset and does not fully satisfy customers, which is why customers return to the company for a specific derivation. The company needs to make a decision whether to rapidly develop and productise a solution for the customer or put it into a proposal for future development. Company B tries to avoid developing a solution for only one customer. RP requires an extra effort because usually the solution needs to fit into the long-term strategy for the company. By doing RP, lower level of investment might reduce the development cost to that of NPD, but might not necessarily be less.
Company B, as an early stage company, views the ability of a customer to pay to enhance their product in a way that the company would eventually do, as optimum. A core business case for RP is having a better product that will grow the company in the future. This is an incredibly strong driver for doing RP even if it is disruptive to the organisation in the short term. When a customer inserts itself into the RP process by having a short-term need that drives revenue, the company tends to be responsive because from the company’s perspective, R&D will be free. This is important. At present, it not only helps Company B to accelerate revenue but also helps accelerate product development, which is a win-win-win situation—a win for sales, for product development, and for the end customer who gets something that is needed.
Company B is working on software as a service model. They would not do RP just for revenue but want the visibility that comes with enhancing a product. Upstream supply chain management needs extra attention. From an interview:
“Upstream supply chain is typically less able to respond than we are, and they are typically less motivated to respond than we are. And that has to do with I think the whole small versus large company thing because we are typically sourcing from larger companies than ourselves.”
If a customer really wants something that is going to impact the experience of the rest of the user community, it obviously carries much more expense from development. One-off or bespoke services are different. When the company does RP, it is a disruption, which is why a product should support the customer, makes it better overall, and leave no negative impact to the customer experience. Parallel RP and NDP are difficult for a relatively small company.
Company C, a telecommunications company located in Maryland, has been incorporating RP for several years, and this causes challenges in the sales situation. Company C’s business is as a small-volume, highly customised industry. RP enables the company to be predictable and to give the customer proper feedback. Historically, if the customer was willing to buy, the company was willing to invent it, and this is how the company developed its product line. Currently the company’s product line offers better conditions, and the company has done sufficient development to ensure the product line can satisfy most customers immediately. The company is now shifting towards stronger prioritisation in product development and are examining whether there are other sales opportunities.
In Company C, the Chief Financial Officer would prefer a world where there are always customer requirements, customer orders, and the engineer is only working on something that the customer is willing to pay for. In the early years of Company C, this was not the case. The main reason to start RP is a business case that will guarantee enough sales, feasible technology to justify an engineering effort, and appropriate prioritisation. RP is a qualitative weighing of nonrecurring engineering effort versus potential sales.
For Company C, the main reasons not to do RP are mainly related to different technically feasible challenges or capacity shortage in the product line, even when the customer is willing to buy a product. One solution to solve capacity shortage is outsourcing resources. From an interview:
“···we have in fact done some of that in the past when we’re just really busy. It’s a way to add bandwidth without having to add to the payroll.”
Company D is a software solutions and consumer goods company located in California. Sales face a need for RP basically every week. The situation is challenging to sales, and employees probably do not manage it as well as they should. First, many customers ask for the same things. In these situations the sales group is able to provide a response because the company is familiar with the question. From the interview:
“I think if you do your work upfront and you need to make self-question does it fit into our business model. Are the bulk of the customers wanting it or willing to commit to buying it? And then, what’s the longevity of the product? Is it a one-time product or is it something that can be offered over and over and over through time? You reduce a lot of your challenges and your risks because you’ve done your work upfront, which doesn’t take that much time, in an effort to better, ensure success.”
However, for a new request where RP is required, they really cannot give a reliable response for at least three reasons: in a typical sales-engineering relationship, sales tend to overpromise and engineering subsequently under delivers. It endangers the business when sales overpromise deadlines and promise certain customers that they can skip a line. From a sales’ perspective, it is all about understanding the customer’s thoughts and the company’s business. Usually the sales person just goes to the marketing team and asks for these new features. In the case where the feature is necessary, it gets advanced on a schedule and other things are moved down; however, if it is a feature that is nice but not essential, it is placed on the wish list.
In Company D, RP should fit a business strategy. Company service builds on the affinity of their buying network. The network can be seen as a scalable layer that accelerates business. RP has to meet financial goals and be profitable. Simply, the company needs to be able to make a profit from RP. The business case for RP will be met when a new product incrementally increases sales and not just splits sales.
Company E is a software solution’s company located in California. The company has not had a single customer that is has paid to build one particular product. Instead they have multiple customers who are interested in similar things. If RP is used for one customer, it requires customer integration on the company’s sales cycle. Even when produced initially for one customer, a product should be useable by other customers. It is typical that a customer is interested in the standard product but wants to see a proof of concept application in the demo that requires the company to build a fast add-on. To do this requires a live demonstration in a configuration using data the customer is interested in. The decision to do or not to do RP depends on the amount of work needed. Sales have an important role and have to define and describe what it is the customer is asking for. From the interview:
“Because sales is always spinning around different crazy stuff development has to stay focused and disciplined to get things done, otherwise they’d be moving around and they’d never finish.”
It is important that a definition of scope is very clear in the case of RP. In the business culture, the sales staff has to be sure they are dealing with people that have the authority to make the decisions. It is important that a customer knows what they want. When the company has a good team to work with and the team has a good dialogue with the customer, it is very constructive, making it safe for the company to do RP.
In Company E, the business cases to start RP are: a reasonable scope, no technical risk to build a product, resources will be available, doable schedule, and the promise given to the customer can be met. Company E is small, and one of the problems with RP is the need to maximise an opportunity cost. When the work has been done, it is essential to leverage effort into a new product line or complement the product line the company is already investing in. To keep it simple, if there is a customer willing to purchase the product, the best business case the company can get is being able to sell the product.
In Company D, the cost of developing is prohibitive and starts to impact the company’s regular business. They have to take people off from developing and selling to do on-going projects. At the moment, the company does not have enough manpower to support RP. If there are five things a customer wants facts for, three of them are ones that the company can do well. The other two customers’ requests will be put on the list for future development.
Company F, is a software solutions company located in California, historically did more RP. Its situation has changed, and currently the company gets more requests for its products, which are equal to market standards and getting more advanced. When the company first started operating, it often needed to provide RP to win clients, but now RP is used more as an enhancement. The company seeks to increase agility just by constantly adding features. A basic software release cycle is 1 to 2 weeks, and the company has a 60- to 90-day release cycle once a year to develop effort-intensive functionality. An ability to balance the work load of development is crucial. It is not good for business if all on-going development needs to stop to address an RP; this happened once and everything else was delayed by 6 weeks. Company F is going to change that in the future. The company’s target is to save part of the business for RP and the rest of the business for its core direction.
There are two business cases for RP in Company F. The first is what the revenue for a client is and this has to be more than $10,000 per year. The second is the question, is it a solution that the company can apply to all their other clients as well to make a greater profit? The main target from RP is to get something for a product portfolio and something that the company can universally use for all their clients. Otherwise, the company tells customers they need to find a third-party developer. The client has to have available resources and must be dedicated to a successful program once the company has built the product.
Company E can earn acceptable profits from RP in terms of pricing and profitability. Problems occur if the products are just one-off instead of products that the company can sell to a number of customers. RP in the company’s market place requires having a lot of employees, which is the main reason the company is not able to do many one-off products.
Company F will never build anything that only one client would own. There is also the need to have them “right client” for RP. From the interview:
“Some of our clients will pick bad developers and they screw things up. And they’ll pay us to fix them.”
The client should also have existing customers available for the product.
Company G, a biotechnology company located in California, was interviewed at the time when RP was needed. The company has the ability to deviate from their platform portfolio, and this has been done several times. From the company’s perspective, it is important to meet the needs of customers and it is something the company is able to do. From the interview regarding how to be agile:
“You know nothing big, fancy, no 10,000 dollar market research studies, just an airplane trip to Atlanta to meet people over a cup of coffee.”
Making fast decisions and quickly developing a new business plan are things that small companies can usually do better than large companies. A request from a customer for an RP in sales is a common topic and in many cases RP can be done. The company has received more and more product portfolio-related questions “···can you have that or this···”, and this has been a recurring event over the past 2 years. It a clear indication for RP and highlights the missing part in a company’s normal offering. The sales situation is all about listening to a customer and then reprioritising the requests. In a small company like G, one of the key management responsibilities is to constantly evaluate how much effort an RP requires versus other development—balancing on-going work and at the same time maintaining opportunities to have flexibility with RP. Management needs to ensure that development is not stuck and prioritisation is constantly being re-evaluated.
Company G has no formal processes because the company and its market are relative small. The company uses unformed processes and relies on market forecasts. The company likes to keep things simple. The business case for RP is a positive return on investment. The business case to start RP requires that there is enough sales, feasible technology to justify an engineering effort, and it is prioritised appropriately. Small companies need their revenue sooner rather than later. The company has to survive on RP development because it generally does not have three or four projects that are on-going.
The main limiting factor for RP in Company G is how to set correct priorities to manage development. From the development perspective, RP requires that everything goes smoothly. When problems occur, these have to be solved fast. RP is not a typical research project.
4. Analysis and Discussion
As a result of this study, the justification for RP in the case companies was described based on the interview data. The interviewed case companies commonly ended up either spinning off a new product or enhancing the existing product based on a customer’s needs. When there is the need to modify products to meet only one customer’s requirements, there has to be a revenue opportunity, which requires that the product functionality later becomes a part of the product/service portfolio available for other customers. A workload impact of RP case should be careful analysed. Portfolio and technology management practises should be in use to support RP. A formal process for reviewing and handling customer’s requests received from RP is essential. As a summary RP in the case companies are:
- Role of sales (salesperson) is critical- Way to resolve situation when current product roadmap does not satisfy customer- Challenge situation in sales and important that the customers know what they want- Way to win clients and meet needs of customers- Sales and R&D integration- Used more in company’s early stage phase- Target to have a portfolio-wide solution not a single customer- Could be needed basically every day- Requires ability to make fast decisions and prioritisation re-evaluation- Quick development of new business plan and
- Right balance between RP, core business, and effort.
As an answer to RQ1, before starting RP a company needs to do more market research and not just react to something that sounds good. Before creating something, a company wants to be able to leverage it across the entire platform. According to interviewees, the basic financial justification of an RP project is based on evaluated income from the project. However, situations where this is not the case were mentioned. For example, an actual feature has already been promised or the deal is somehow secure if the customer requirement can be met. One interviewee even mentioned that some projects are justified primarily based on intuitive decisions about profitability. It was also pointed out that these projects must have full support from top management. Table 2 summarises the objectives for the RP business case.
To address RQ2, a sudden need for RP in sales is a challenging task for sales people. It endangers the business if sales overpromise deadlines and promise certain customers that they can skip a line without better knowledge of what is needed. Challenge areas for RP from management are: 1) a relationship between sales and engineering, 2) sales not overpromises and/or overestimates requirements, and 3) engineering will not under deliver. Sales have to ensure they are dealing with people that have the authority to make the decisions. It is important that a customer knows what he or she wants. It is best when a customer has some technical knowledge in an area under sales negotiations.
When RP is targeted to more than one customer it will require an extra effort because the solution needs to fit into the longer term strategy for the company. An essential issue for RP is that sales, development, and management know how the customer’s request for the product/ service fits within the objectives and scope of the company’s strategy. Table 3 summaries the RP challenges of the case companies.
To address RQ3, the business is not feasible if all ongoing development needs to stop for tackling RP. This happened with one case company and other work was delayed for 6 weeks. The company is going to change
Table 2. Objectives for RP business cases.
this in the future. The company target will be save part of the business for RP and the rest of the business for the core direction. Are the financial benefits so big that the project is worth doing even if partner companies must be used? Is the project a possible entry to a new customer segment or market area or even a new single customer that is big enough? One key point to address is also whether the project would help the company in differentiation from competitors. The company should also be able to test the solutions early on. RP is justified if it creates new business. The analysis is always made beforehand based on the business reasoning and resources the company has available. Businesses reasoning for RP are presented in Table 4.
5. Conclusions
The starting point is to utilize company’s existing products and services. The required speed is achieved by only focusing the development on limited elements of the product, enabling concentrating on essential aspect and “fast tracking” the development. The cooperation among sales and product development must be seamless during the process. It is essential when using RP that the RP process is dynamic and that all advantages of existing frameworks are fully integrated. Responsibilities between sales and R&D need to be clear. After starting RP, conversations between sales and R&D need to be smooth and objective. In the company, everyone should be on the same page. Well-executed portfolio management in cooperation with RP is one way to minimise unnecessary growth of product variety.
Use of third-party vendors to support a resource shortage needs to carefully examine because vendors could be less motivated to respond and it might cause challenges
Table 3. Summary of RP challenges.
Table 4. Business reasoning for RP.
in a later phase. Being able to keep a promise given to customers is a must for RP. Company has the ability to lose the trust of a customer only once.
Using RP does not mean that product development costs are automatically small. Cost of development might be the same as NPD and not necessarily be less. RP requires sufficient sales potential and should be technologically feasible. It must be able to justify the engineering effort and be able to prioritise appropriately. RP is a qualitative weighing of nonrecurring engineering effort versus potential sales.
5.1. Managerial Implications
The first signal for the potential need for RP comes from the customer, typically during a sales situation when the existing product portfolio does not fully meet the customer needs. One proposal for how management could solve the challenge in sales negotiations is to explain to sales people where the company’s market is compared to the full market place. Sales should increasingly look at not just whether there is one sale but could there be several sales opportunities.
Has the company capacity to spare for the project? In small companies, one of the key things that management needs to do is constantly evaluate how much effort could be put to RP versus other development (i.e., NPD). Management needs to balance on-going work and at the same time maintain flexibility for RP opportunities. Management needs to ensure that development is not stuck and that prioritisation is being re-evaluated. Project management tools should support PR case analysis proving up-to-date information of NPD program(s) status (critical path) and actual vs. estimated workload.
5.2. Limitations
This study has focused on small business use of RP. Addressing some of the limitations of this study should stimulate further research. First, the number of interviewed companies is limited; a deeper analysis is needed to broadly cover the studied topic. Secondly, our study focuses on small companies. The next step would be to study what might be reasoning for RP in large companies. Third, it would be interesting to examine in more depth how new companies can utilise and take advantage of RP to boost companies’ early growth.
Acknowledgements
This study was carried out as a collaborative effort by the RapidPRO II project funded by the Finnish Funding Agency for Technology and Innovation (TEKES), MikroY project funded by the European Regional Development Fund (ERDF), and with collaboration with the University of Maryland, College Park, Maryland, and the University of California, Rady School of Management, La Jolla, California. The aim of this collaboration was to add new information on the upstream supply chain and RP to the knowledge base. We appreciate the companies involved in the study for sharing their experiences.
NOTES