Grzegorz supports smart technically-minded people as a business consultant and COO.

Grzegorz Rduch

Sometimes outsourced development projects fail. Study post mortems documenting such failures or talk to people who were involved in failed projects, and you will discover that failure was often rooted in mediocre team organisation and meager management practices. Team architecture was poorly defined, roles and responsibilities of each individual were not documented or understood and ownership was not clearly divided. Finally, and possibly most importantly, the key roles on the team were filled with people who just did not have the makings to make it work. Who are the cornerstones of the team architecture you need to outsource software product development successfully?

### **A John Wayne solo act?**

Product championship calls for a powerful combination of both** business/market and technical** skills. Ideally, you would like to have ONE person to be able to provide the complete skill set needed. Even if you find one, the tasks, duties and responsibilities associated with such a large role are so numerous that they may be too expansive for a single individual to manage. Consequently, a team of TWO people are much more likely to cope with the challenge and ensure the combined market/product, technology and process leadership you are after.

### **The tandem that pulls it off**

So, in principle, you will need at least two key players as the foundation of your team structure. One to manage the front-end, **customer-focused** part of the development process and the other to take care of the back-end,**technology-oriented** product development job. If you are a fan of [S.G. Blank](https://steveblank.com/), you may as well think of the two as the managers of Customer Development and Product Development processes respectively. The first thing thing is to ensure both perspectives and skills are at hand, and the next is to ensure they smoothly act in sync. Get both on your team and ensure they collaborate effectively, and you are much more likely to create a great product.

### **The Product Owner**

Your product champion, leader or owner – whatever you call them – has extensive domain expertise and great empathy for the customer/user. This understanding allows them to see what is essential rather than incidental and helps them ensure a good product-market fit. As regards organization, this person is usually the entrepreneur founding a new venture or an entrepreneurial in-house manager responsible for: _ the delivery of the project _ product management day-to-day interactions with customers/users, the outsourced team and other project stakeholders A word of caution. If you split the role into Project Manager and Product Owner, specify clearly their areas of responsibility and the associated TDRs to ensure ownership and clear lines of communication.

### **The Tech Lead**

Your Tech Lead or Chief Engineer – again, the formal label does not count as much as the contents of the role – has the expertise to see what is possible. This person co-creates the product through technological insights and contributions. They are usually in charge of the product development team and supervise product development activities on a daily basis. They are to free the Product Owner from the time-consuming management of developers at the task level. A word of caution is in order, however. Even if the Tech Lead is your in-house co-worker, establish a delivery manager at the vendor with full responsibility for development team management. The vendor’s manager should accept responsibility for any work delivered by your vendor’s staff and act as a single point of contact for efficient communication and decision making.

### **Let the team architecture unfold …**

If you have the Product Owner and the Tech Lead who feel personally responsible and accountable for the success of your product, or even better, who identify with the product, you may assume you have a solid foundation on which to lay the rest of your team . You can now begin to further define its architecture. Whatever the details, clearly specify the structure of the project team, accounting for both internal and vendor resources you will need. Specify roles and the associated responsibilities, document them and ensure they are understood by all the people involved.

### **A note on outsourcing**

How should the roles be located within the team if you outsource your software product development? You are unlikely to outsource the Product Owner’s job, if only for the fact that the near-/off-shore vendor is ill-suited to manage the front-end, customer-focused part of the development process. Still, it does not mean that great, proactive teams are unable to go beyond the technical and offer valuable product and business insights. Unlike the Product Owner, the Tech Lead may be either your in-house co-worker or the vendor’s manager, depending on the skills and resources available in-house. In the latter case, they both need to be prepared for intense collaboration to keep the customer and product development in sync. As a rule of thumb, the more agile the methodology and the less precise the technical specification, the more frequent the communication exchange between the two key players needs to be. As such, your Product Owner and the vendor’s Tech Lead lend themselves to act as a single point of contact between you/your company and the vendor. Such an arrangement facilitates fast decision making (which need not preclude collaboration on a wider basis between you and the vendor’s team.) If you are not the Product Owner yourself, make sure the one who is has sufficient authority to act efficiently, i.e. to approve the work delivered. Ultimately, both sides want to avoid unnecessary delays and frustration which may otherwise burden their collaboration. It is also helpful when the Product Owner has some technical background while the Tech Lead has a degree of domain knowledge gained on earlier similar projects. Such expertise overlap allows both to better understand each others’ role and vastly enhances the efficiency of collaboration.

### **Who to look for?**

All in all, while sourcing, make sure you carefully select not only a software development house, or rather a team, but also – possibly, first and foremost – a key player to be a cornerstone of your team. Do not simply purchase a service – hire people to work on your project team. Set selection criteria and conduct due diligence on both the company and the specific individuals you are to collaborate with – in particular, the person leading the vendor’s team. Look for an individual who: _ has sufficient** communication and cross-cultural skills** to ensure smooth collaboration _ possesses rich **technical expertise** you need for your project and thus is able to make significant technical contributions _ preferably, **knows the application domain** so that you do not spend much time getting them in the picture _ is able to present a **proven track record** of experience on similar-size-and-type projects delivered successfully leads a stable, cohesive **team** that follow a well-defined software development **process** Last but not least, make sure the Tech Lead is the person you / your Product Owner feels comfortable to work with and the attitude is reciprocated.  After all, you are both in for intense collaboration in the months, if not years, to come. I am not trying to say you are hiring an individual. All I am saying is that this individual is key to outsourcing successfully.

### **Sourcing Tips**

How can you increase the odds of finding the right person? _ Scrutinize their personal profile / CV. _ Browse through their professional networks. Are they likely to scale their team fast enough when needed? _ Check their personal references, in particular the references from the customers they have served. _ Conduct interviews with the Tech Lead and their team. _ Check the projects the Tech Lead delivered – not necessarily only their company’s. On larger engagements, you may as well: _ visit the company or have the Tech Lead come and deliver initial service, e.g. tech spec and system design, on-site have them deliver a pilot project. It is the Tech Lead and their team that need to convince you they have the expertise with the specific technology stack and have successfully completed projects for other clients using your target technology. All in all, apply recruitment tactics on top of more formal B2B purchasing procedures. All of it should have one objective in mind – to establish if the candidate has the makings to lead your back-end product development team and ensure you outsource successfully.

### **Conclusion**

To sum up, when organizing the team to deliver your software development project, make sure it has a solid foundation in the the form of a tandem of a Product Owner and a Tech Lead. Fill in the key roles with the right kind of individuals before you embark on the project, and you have vastly increased the chance of being a success in your quest.

Sometimes outsourced development projects fail. Study post mortems documenting such failures or talk to people who were involved in failed projects, and you will discover that failure was often rooted in mediocre team organisation and meager management practices.

Key Players In Outsourced Software Product Development

I have recently been approached by a good friend of mine, [Wojtek Pander](https://www.linkedin.com/pub/wojciech-pander/5/73/4), and asked for a contribution to his research paper on Open and Customer / User-Driven Innovation. I immediately thought the best we, here in Selleo could do to contribute, would be to share our very down-to-earth insights gathered together from our clients on over 30 software development projects. I also knew that the focus would have to be on the customer / user involvement in the software development process, i.e., the front-end part of the process which is usually controlled by the client rather than their vendor, who are preoccupied with technical product execution.

Our clients – the product owners – varied widely in their approach towards customer/user involvement in the process. Some of them got their customers engaged very early on and kept collaborating with them fairly intensely; those clients consistently verified their own assumptions against the feedback and data gathered from their target group and used the input to manage their product scope. Others were less willing to do so; they chose to manage their products by themselves. In some extreme cases the product was first exposed to the customer only after over 12 months from the project kick-off.

Though the number of clients we have served does not allow us to draw significant statistically valid conclusions, the pattern that has emerged is quite clear. In a nutshell, we have observed that **customer / user engagement in the design and development process allows the elimination of, or at least the reduction of, a number of risks and increases the odds of market success**. The products developed are better and they are more likely to fare well in the market. Needless to say, not doing so has the opposite effect. Not surprisingly, our observations are borne out by a number of accounts we have heard from developers working for other software development houses. The pattern seems fairly consistent.

\(From now on I shall stick to the term “customer”, though it is worth bearing in mind that it is not always synonymous with the user; depending on the type of solution, you may have to deal with customers who are users or else with separate groups of customers and users. When I refer to the “customer”, I broadly mean both groups, i.e., all those for whom a given solution is to be created.)

**What you risk when you are not customer-driven in your approach**

Those who design and implement their solutions without customer involvement or engage their customers late in the process are very often confronted with the following phenomena:

**1. Lack of / poor product market fit**. They often implement solutions which find no / too few customers and, as a result, do not generate revenue which allows them to recover their investment. In an extreme case, when the first customers were eventually approached with the product, it turned out they perceived it as a threat to their market position rather than an opportunity to exploit. The sales attempts were futile.

**2. Solutions burdened with extraneous features**. The systems very often get loaded with features and functionalities the customers never / hardly ever use, let alone are ready to pay for. It needs to be stressed that such irrelevant features can have a negative impact on the ease of use of those functionalities that the customer does need.  Thus the former may decrease the overall value of the solution. In one case, a target customer actually agreed to purchase the solution as long as the provider agreed to simplify the product by removing a number of features implemented and available in the product. Classic waste.

**3. Products loaded with unnecessary complexity**. Some build solutions which are much more complex than they really needed to be.

**4. Laborious late-stage modifications (rework)**. Those who fail to listen to their customers often fail to correct their course early on and risk having to do so late in the process, e.g. after the product has been shipped to the customers. In principle, the later you need to modify the solution, the greater the workload and cost associated with the change.

All the phenomena mentioned in the points above lead to:

**5. A significant increase in development expense, including the costs of QA**. We should stress the impact of the cost of complexity and emphasise that the cost is exponential rather than linear in nature. When system complexity increases, so does the cost of enhancements and support. Thus extraneous features not only generate costs associated directly with their implementation but they also increase the costs of introducing features and functionalities in the later stages of product development. Litter the system with trivia and you may close the way for what is truly needed.

**6. Increased cost of system support and maintenance**.

**7. Increased [cost of delay](https://www.softwaredevelopmentoutsourcing.eu/cost-of-delay-insights-for-better-product-scope-management/)** and the associated market risks. Applications built without customer feedback often take longer to develop and launch. It is particularly destructive in the case of innovative projects where time is a very sensitive issue. Delays significantly increase the risk of market preemption by a faster competitor or at least lead to a decrease in the market share that can be monetized. In one case, we saw our client working in the back office on milestone 7 while their competitors were releasing products with only 20% of the functionality we already had in our system.

**8. Increased technology risks**. Delays in implementation increase the risk of changes in the underlying technology. Take too long to develop the product and you may discover you need to implement modifications you did not (and could not) plan for.

**9. Negative impact on your team’s motivation, engagement and productivity – increased risk of attrition and knowledge loss**. This negative impact concerns both your in-house team and the vendors’ you are using.

**10. Negative impact on customer engagement**. By getting the customer involved you facilitate the adoption of your solution. A sense of ownership which stems from collaboration helps a lot when the solution is to be applied by the customer. Fail to engage the customer and you may find out it is much harder to win the customer over when the solution is to be deployed.

All in all, when you eliminate the customer from the design and development process, you are very likely to be confronted with a number of phenomena which increase the odds of failure on your project. What – specifically – can you do to increase the likelihood of success then?

### **Success Story – Frontal Solutions AS and the Metreno Platform**

[Frontal Solutions AS](https://frontalsolutions.no/) is a Norwegian consulting company providing services and software solutions which facilitate their clients’ HRM functions and internal communications systems. They deliver their services to medium-sized and large enterprises. One of the solutions is the software platform [Metreno](https://metreno.com/users/login) which is used to manage HR surveys and internal communications measurements.

**The platform was designed, developed and implemented in very close collaboration with Frontal Solutions’ target customers.** The latter were involved in the process from a very early stage of product design, and the systematically gathered feedback they provided in successive product iterations has enabled Frontal Solutions to efficiently deliver a solid software tool which addresses very tangible problems their customers are confronted with. Frontal Solutions have been using the following **methods** to get their customers involved in the design and development of their software platform:

* the **initial product concept and project scope.** was developed, or should we say – **co-created – together with their target customers**. The customers played a vital role in defining the problems to be solved, specifying the high level requirements for the solution as well as prioritizing specific modules, features and functionalities to be implemented.
* it should be stressed that to the extent possible, Frontal Solutions prefer to avoid using structured interviews and rely on more **open, dialogue-based brainstorming sessions** to better explore the opportunities to take advantage  of and the limitations to neutralise. The formula ensures that both sides are equally equipped to contribute valuable insights in the process. It is only in the future, when the product functionality solidifies, that Frontal Solutions intend to use a more structured approach to gathering feedback.
* more detailed technical **specifications, especially visual mockups** (!), developed for successive iterations by the Frontal Solutions team, are **verified with the customers**. The approach enabled Frontal Solutions to introduce changes very early on, i.e., before development started.
* having implemented a module or a set of functionalities, Frontal Solutions carried out **acceptance tests together with the customers** to further ensure compliance with their customers’ requirements and expectations. The co-testing, among other things, helped Frontal Solutions verify some of their assumptions concerning what “user friendly” really meant for their customers’ users. after each module had been deployed in the customer’s production environment, the **customers/users provided valuable feedback that has continued to guide Frontal Solutions in their decisions to modify, complement and optimised the solution** delivered. In principle, the less standardised the module or else the more innovative the solution, the more intense the collaboration that is needed.
* Frontal Solutions have also used \*\*analytic methods \*\*to optimise Usability / User Experience, specify the requirements concerning browser compatibility and schedule of activities meant to increase the performance / scalability of their application.

[Frode Jakhelln Laugen](https://no.linkedin.com/in/frodelaugen) – Frontal Solutions founder and Managing Director, is convinced that **the adoption of such a customer-driven approach has allowed his company to:**

* build **a solid solution which has found paying customers.** A good product that meets the target customers’ needs is the best facilitator in the sales process, and with the customer involved in your product development process you are more likely to arrive at what the customer considers to be a good solution,
* increase the level of **customer satisfaction** as well as stimulate the customers’ sense of ownership, which leads to customer engagement in the implementation phase. Customers are more likely to accept a solution they have co-created rather than a solution that is “imposed” on them,
* **avoid** (reduce the number of) late-stage modifications, a lot of **rework** and the associated costs,
* avoid the implementation of features and functionalities which bring little or no value to their customers. This in turn allowed Frontal Solutions to **limit the complexity of the system and reduce the investment outlay needed**,
* **shorten the implementation cycle** and deliver what the customers were after much faster. A modular product architecture and a matching pricing model used have enabled Frontal Solutions to speed up revenue generation and thus allowed the company to partially refinance the further development of their product,
* increase the level of **motivation** on the product development team,
* it should be noted, though, that customer involvement does require effort and takes time and as such is associated with upfront costs; the investment, however, pays off later on in the product life cycle.

### **The benefits of the customer-driven approach.**

Allow me to reiterate the key points. Properly engaged customers and/or users provide insights and invaluable feedback which helps you to verify initial assumptions and better manage the product scope. Proactive customer involvement allows you to:

ensure better product market fit and higher customer satisfaction, which increase the odds of generating the sales with which to guarantee return on investment, make the decision to discard the project or pivot much earlier, saving you the irrecoverable cost of walking down a blind alley, verify your assumptions and introduce changes in the early stages of product development limiting expensive rework further down the road, significantly reduce the risk of implementing extraneous features the customer will never / hardly ever use; thus you lower the cost of development, support and maintenance, including the cost of complexity, shorten the time to market, lower the cost of delay and eliminate some of the market and technology risks involved as you have less workload on the plate end up with more engaged customers, co-workers and suppliers.

### **Conclusions**

Some entrepreneurs / Product Owners concentrate primarily on building technical specifications and collaborating with their product development teams. In doing so, they significantly limit their customer-focused activities and thus miss an opportunity to gather invaluable customer feedback with which to build a better product faster. Such an approach increases the likelihood of failure. Short and bitter. If you intend to build an innovative product / venture, strive for early, intensive and consistent customer involvement. Define the role of the customers in the process upfront and stick to you plans. Get the customers involved in the specification, design and implementation of your solution. You should:

* verify your product concept and initial project scope with early target customers,
* engage them when working on requirements and specs,
* seek their feedback on successive product iterations.

When possible, accept and test new deliverables with the customers and use their feedback to review your backlog priorities and schedules.

All in all, if you are after innovation, seek customer involvement in the process. As a rule of thumb, the bigger the market risks, the greater the involvement needed. Do not stay locked up in the ivory tower of back-office product development. Many technically splendid products have never found the customers they were meant for. I actually wonder whether there is an alternative to the customer-driven approach. I mean, a more effective alternative.

**Post Scriptum**

Practical tips on how to build and develop software products and ventures based on customer / user feedback can be found in publications and speeches by, for instance, S.G. Blank, E. Ries, A. Maury, D. McClure, S. Ellis, A. Chen. If you are after short narratives by tech entrepreneurs, I recommend the illuminating case studies and tips you may find in [Do More Faster](https://www.amazon.com/Do-More-Faster-TechStars-Accelerate/dp/0470929839).

Those who design and implement their solutions without customer involvement or engage their customers late in the process are very often confronted with the following phenomena.

Customer Driven Product Development A Report From The Trenches

The [Startup Genome Project](https://blog.startupcompass.co/) is an initiative launched to identify what makes Silicon Valley startups successful as well as to share the findings with entrepreneurs in other parts of the world.

In their first step, the [Startup Genome Report](https://blog.startupcompass.co/discover-the-patterns-of-successful-internet) – the organisation analysed the data from 650+ web startups and developed a framework which is believed to shed more light on the factors behind startups’ success. One of the key findings of the research project is that founders that have supportive mentors, track metrics, and **learn from startup thought leaders** raise 7x more capital and have 3.5x better user growth. In short, startups that learn are more successful.

Assuming a tech entrepreneur or an enterprise intrapreneur would like to increase their odds of success through learning from thought leaders, who should they turn to? In the section Learning As The Key To Successful Startups’, the report makes a specific references to [Steve Blank](https://steveblank.com/about/), [Eric Ries](https://www.startuplessonslearned.com/2008/10/about-author.html), [Dave McClure](https://500hats.typepad.com/500blogs/about-dave-mcclure.html), and [Paul Graham](https://www.paulgraham.com/bio.html). We can add a few more to this fine company. Who are these thought leaders then and what are their key contributions? How can you benefit from them?

 

 

### OSTERWALDER AND THE BUSINESS MODEL CANVAS
Back in 2009, [A. Osterwalder](https://alexosterwalder.com/) [@business_design](https://twitter.com/#!/business_design), Y. Pigneur and a crowd of 470 practitioners co-created and self-published the book [Business Model Generation](https://alexosterwalder.com/books.html) – a handbook – or rather, a practical guidebook on how to design tomorrow’s businesses. The key tool they provide you with is the [Business Model Canvas](https://www.businessmodelgeneration.com/canvas), which is a 9-building-block template with which to describe, analyze and (re-)design the business model of your venture. On top of that, the book explores emerging business model patterns and the techniques to build business models and also offers insights on how to re-interpret strategy using the business model.

 

The Business Model Canvas not only helps to create and explore a business model; equally importantly, it enables you to easily share you ideas with the other stakeholders involved, such as, for example, your business partners, investors or a technically-oriented product development team. As such the BMC helps to ensure that everybody involved is, literally, in the same picture and, as a result, has a strong foothold from where to make meaningful contributions. Watch the [video](https://www.youtube.com/watch?feature=player_embedded&v=QoAOzMTLP5s) to find out how the tool works. You may as well visit the [Business Model Hub](https://businessmodelhub.com/) to share your insights with the community gathered around the concept.

 

An afterthought. Though the Business Model Canvas has most typically been applied to new ventures, there is no inherent reason why it should not be used by established enterprises to better manage their new product initiatives. I think the tool can even be modified into a Product Model Canvas with which to address the issues in new product reasearch, development and launch. Just as it may help to bring a startup’s stakeholders together, it may be a tool with which to empower a cross-functional team working on a new product in an established company.



### S.G. BLANK AND THE CUSTOMER DEVELOPMENT FRAMEWORK
Let’s assume for a while you have developed a Business Model for your venture, you have even produced the requirements and tech specs for you product or platform. Should you now go on to implement it in a waterfall kind of way and launch it when it is ready? Many entrepreneurs and enterprises have done so only to find out – painfully – that their state-of-the-art feature-rich products do not resonate with the market – they have failed despite having a great product. Luckily, there is Blank [@sgblank](https://twitter.com/#!/sgblank) with his Customer Development framework which helps to mitigate such risks, at least to some extent. The term “Customer Development” refers to the practicies and processes involved in setting up and building startups into viable businesses. In his [lectures](https://ecorner.stanford.edu/authorMaterialInfo.html?mid=2048), the book *[The Four Steps to the Eppithany](https://www.stevenblank.com/books.html)* and [blog](https://steveblank.com/) posts, Blank describes and advocates an actionable framework which guides you on how to build a scalable business rather than merely a product. To put it in a nutshell, product development by itself is insufficient to ensure success; it needs to run in parallel with the market / customer development process – the process of hypothesizing, testing your market and product assumptions and learning in successive iterations. What you start with are merely assumptions that have to be verified and very often changed while developing your product / venture. It is worth mentioning that Blank’s framework may be applied to new product development in a variety of business contexts and is not limited to web startups. It is an approach which enables product developers to greatly reduce the market risk their products or product-based ventures are confronted with.

 

### TAKING IT FURTHER TO ADVANCE WEB STARTUPS
A number of people have decided to build upon the Customer Development framework and, in particular, adjust it creatively to fit the web startup context. Some exemplary representatives of the movement are: 

**Eric Ries** [@ericries](https://twitter.com/#!/ericries) – the creator of the [Lean Startup methodology](https://www.youtube.com/watch?v=fEvKo90qBns) and the author of *[The Lean Startup](https://theleanstartup.com/book)* book as well as the [blog Startup Lessons Learned](https://www.startuplessonslearned.com/). The Lean Startup approach combines Customer Development practicies, Agile / iterative development methodologies and the use of low cost open source development platforms. The combination allows a substantially reduction in waste and market risks in web venture development.

**Ash Maurya** [@ashmaurya](https://twitter.com/#!/ashmaurya) – an entrepreneur who has developed a variation of the Business Model Canvas, i.e., the [Lean Canvas](https://leancanvas.com/products), and built on Blank’s ideas to develop a web startup version of the Customer Development process. Ash started off with the Blank’s framework and early Ries’ ideas on Lean Startup. He did not adopt them passively though; he has applied the ideas on a number of his own product development projects and subsequently modified the frameworks and tools so that they fit the web startup context better. You can read Maurya’s book –  [Running Lean](https://www.runningleanhq.com/) or turn to his [blog](https://www.ashmaurya.com/) to find out more about his methodology as well as his experiences connected with product development projects he has worked on. As a founder and CEO of [Spark59](https://www.spark59.com/), Ash is now on a mission of helping other startups raise their odds of success.You may find some of their resources to be of help for you too.

**Dave McClure** [@davemcclure](https://twitter.com/#!/davemcclure) – a venture capitalist and a seed fund founding partner who developed the concept of [AARRR Metrics](https://500hats.typepad.com/500blogs/2007/09/startup-metrics.html) – a set of lean startup metrics, and thus offered a method to measure progress throughout the Customer Development process for web startups. To go deeper into the topic of web startup marketing and metrics, you may as well explore the blogs of [Sean Ellis](https://startup-marketing.com/about/) [@9SeanEllis](https://twitter.com/#!/SeanEllis) and [Andrew Chen](https://andrewchenblog.com/about/) [@andrewchen](https://twitter.com/#!/andrewchen).

 
**Paul Graham** When on a hunt for advice on how to build new software solutions and launch web ventures, you may also choose to follow the insights offered by [Paul Graham](https://www.paulgraham.com/bio.html) [@paulg](https://twitter.com/#!/paulg) – an essayist, programmer and investor who has been in the business for quite some time already. Many of his [essays](https://paulgraham.com/articles.html) contain useful tips which may help tech entrepreneurs and startup founders to avoid the pitfalls and exploit the opportunities they are presented with on their entrepreneurial quest. Go over a few of his most popular essays to get the feel of Graham’s contribiutions. [The Hardest Lessons For Startups To Learn](https://paulgraham.com/startuplessons.html), [Startups In 13 Sentences](https://paulgraham.com/13sentences.html), [The 18 Mistakes That Kill Startups](https://paulgraham.com/startupmistakes.html), [What Startups Are Really Like](https://www.paulgraham.com/really.html).

  

### D.G. REINERTSEN AND THE PRODUCT DEVELOPMENT FLOW
Now that you are quite well equipped with Customer Development tools and frameworks, which enable you to increase the odds of building the right thing, you can turn to D.G. Reinertsen [@DReinertsen](https://twitter.com/#!/DReinertsen) for more practical principles with which to better manage the economic and technical aspects of the product development process. If you are into product development, be it as an entrepreneur or an R&D department employee, you can enrich your perspective and strengthen your workshop by exploring Reinertsen’s valuable contributions. They have been presented in Reinertsen’s three books.Like the other contributors featured in the article, Reinertsen has been relentlessly  questioning the product development orthodoxy and offering pragmatic principles you may apply to increase the odds of success on your product development projects. His insights on project economics, the impact of queues, variability and batch size, Work-In-Progress constraints, cadence, feedback, flow, decentralized control, etc., may guide you to properly manage you product development efforts. I have seen his principles applied in practice to improve a few misaligned development projects; they worked. 

If you, for instance, still believe that 
* the life-cycle profit is not the best measure to drive your product development decisions 
* you do not need a product-specific implementation strategy and can optimize for scope, time and cost simultaneously, without economic trade-offs 
* there is no costly inventory in the product development process 
* it is desirable to load your resources to high levels of utilization to increase the efficiency of your processes 
* you should eliminate variability in product development AND still be able to innovate 
* you should insist on conformance to the original plan 
* large batch sizes have scale economies and thus increase efficiency 
* you strive to control timelines rather than queues 
* you do not need WIP (work-in-process) constraints 

it’s a good idea to centralize control for efficiency’s sake then you may come to realize that your beliefs can be more of a hindrance than a help in your product development efforts. To catch a glimpse of Reinertsen’s ideas, watch the [video presentation](https://www.infoq.com/presentations/2nd-gen-lean;jsessionid=6B4F2A7D30DC0CB3FA7A3C261ADC2BD7) on Second Generation Lean Product Development recorded at the 2009 Lean and Kanban Conference in London.

 

 

### CONCLUSION
The thought leaders are working towards the same goal – to support tech entrepreneurs in their product / venture development efforts. Not surprisingly, their contributions often complement rather than contradict each other and their concepts, tools and advice may be combined to create much more valuable frameworks. One good example presented above is the approach drawing on Osterwalder’s Business Model, Blank’s Customer Development and Agile Development practices. Browse through the [presentation](https://www.slideshare.net/Alex.Osterwalder/successful-entrepreneurship-5747012) or visit [Blank’s blog](https://steveblank.com/2010/10/25/entrepreneurship-as-a-science-%E2%80%93-the-business-modelcustomer-development-stack/) for more details on the combined tool stack. This is by no means the only possible hybrid. If you are looking for tools and advice with which to build profitable products or foster you product-based startup, you may as well choose to refer to the sources cited above. Good luck on your knowledge quest! Good luck on your professional / business journey!

One of the key findings of the research project is that founders that have supportive mentors, track metrics, and learn from startup thought leaders raise 7x more capital and have 3.5x better user growth. In short, startups that learn are more successful.

Read our articles on Selleo Blog

Business

Technology

Key Players In Outsourced Software Product Development

Customer Driven Product Development A Report From The Trenches

Product Development And Tech Entrepreneurship Thought Leaders

Tell us about your project