Never Start Innovation with an Idea

Are you trying to come up with the next big idea to jump-start innovation in your company? Try another approach. Gijs van Wulfen gives us three reasons why you should not start an innovation initiative with new ideas, rather formulate a clear and concrete innovation assignment. Here’s how!

The fuzzy front end of innovation confronts you with a lot of questions. Please have a look at book ‘Creating innovative Products and Services’ where author tried to solve this with the FORTH innovation method.

Never start product or service innovation with an idea. Of course: innovation is initially about ideas. About getting the right ones. And realising these ideas in practice. A shining light bulb has become a global symbol for innovation. Just check Google images and type innovation and then you will see proof of this.

There are three reasons why you should not start with an idea.

  1. An idea makes you blind. Once you got your idea you will probably fall in love with it. That’s a great feeling indeed. But love makes blind, unfortunately. The psychological phenomenon of selective perception will make you see only the positive points of the idea and only listen to people who are supporting you. And in trying to realise the idea you will run in 80 percent of the cases into a hard wall, which will wake you up. Not having an alternative available to realise your personal challenge.
  2. It’s very difficult to convince others. What happens when you tell your idea to someone else? Their first reaction starts often with a ‘but……….’. Others within your company will start criticising your idea the moment it is told to them. An important reason is that the idea is not theirs. Furthermore companies and organisations are organised to get a grip on the current operational processes and to give account of the results produced. Should the size and complexity of the organisation increase, innovation becomes more difficult. The process of innovation seems almost unnatural. A solution is getting ideas together in a team setting so the ownership of the idea is shared.
  3. Only one and a half out of seven new product ideas is really introduced. A number of studies on new product innovation (Robert G. Cooper, 2011) showed that for every seven new-product ideas, about 4 enter development, 1.5 are launched and only 1 succeeds. These are poor odds. There is a chance of around 1 out of 5 that your idea will reach the market. So what do you do when your boss, the vice-president marketing or the innovation board stops your new product idea? Do you have any alternatives available to realise your business challenge? So never bet on one horse. That’s the message.

So, how should you start innovation?

You should never start an innovation expedition unprepared. As good preparation not only increases the chances of success but it also creates priorities, direction and the will to succeed. That’s why it is essential to start with a clear and concrete innovation assignment. This forces the top management in your company, from the start, to be concrete about the market/target group for which the innovations must be developed and which criteria these new concepts must meet. This forms the guidelines for you and your innovation team when you are underway. You can formulate the innovation assignment with the help of the following six questions:

  1. Why?  (Why do we want to innovate);
  2. Who?  (Who is the target group);
  3. Where?  (For which distribution channels, countries, regions or continents);
  4. What?  (Evolutionary or revolutionary; products, services and/or business models);
  5. When? (Intended year of introduction);
  6. Which? (Which criteria the new concepts should meet);

So in discussion with your top management, you can collectively formulate which criteria the new product/service ideas must meet as well as determine the ambition level.

Product Assumptions – Which one are you making today?

When a team sets out to develop a product, they generate a series of hypotheses. In my experience, good teams are explicit about these hypotheses and test them before they invest too much time into a particular product plan. However, more often than not, I see that development teams are not even aware that these hypotheses exist, instead building their products as if they were fact. The problem with this approach is that rarely does a team get all, if any, of these hypotheses right from the get-go. If they don’t first test them, they run the risk of building a product that nobody wants. Let’s take a look at an example to illustrate how this works.

Explicitly Enumerating Product Assumptions as Hypotheses

I have an idea for a Delhi Metro mobile app. DMRC is the local Metro train that runs with-in NCR regions. Riders include daily commuters and occasional train riders. As a daily commuter, I witness a number of problems experienced by occasional riders. They don’t know how to buy tickets, they don’t know how to pay for parking, they don’t know which platform to stand on. They don’t know how to tell what stop they are at.

I suspect that if DMRC tackled some of these problems, they might convert more of these occasional riders into daily commuters, growing their ridership. I’ve often considered building a DMRC mobile app that addresses some of these usability problems.

The app would walk the occasional train rider through each step of the process of riding the train, starting with where to park, how to buy a ticket, updates on when the next train is coming, updates on where you currently are relative to where you want to get off the train. My goal would be to make it as easy as possible to ride the train.

I know how to do all of these things. I’m observing these problems first hand from past 1 year. Should I just get started and build the app? How do I know that occasional riders will want it?

Let’s take a look at some of my assumptions or hypotheses underlying my app idea.

  • H1: Occasional train riders will download a DMRC mobile app before they ride the train.
  • H2: The problems that occasional train riders experience are big enough that they will remember to use the app they downloaded earlier to help solve their problems.
  • H3: The desire to ride the train is great enough that if occasional train riders had help they would ride the train more frequently.

It’s quite possible that occasional train riders don’t anticipate having problems. If they did, they would probably choose to drive rather than take the train. So H1 could be a big hurdle.

H2 may not be as big of a hurdle. It’s possible that if I did download the app and I run into a problem, the problem itself may act as a trigger to remind me I have the app. But that still needs to be tested. It might be easier for me to just ask somebody nearby. Or I might just give up, something I see people do daily.

With H3, if my goal with the app is to help grow DMRC ridership, then I am assuming that the reason people don’t ride the train more often is because it’s hard. This might be part of the problem. But there are a number of other reasons why occasional riders might not take the train more often – the big one being that it is often slower than driving. Even if people had all the help they needed, they might still choose to drive over taking the train because they simply want to get to their destination sooner.

Now I need to find out the solution for testing these hypothesis, till then cheers!

Everything is a Product Management

The basis of the post is this: Everything is a product management problem. Not just the product. Not just features. Not just platforms. Everything you do.

The same techniques and skills you use to manage product development can be applied to your startup, your business plans—and you, yourself.

It’s about compromises and resources and time. It’s about ship dates. It’s about controlling feature creep. It’s about making go/no go decisions. It doesn’t matter whether you’re an engineer, marketing, management, or sales. In the startup world, everything is a product management problem.

With that in mind…

Everything is a product management problem

Now, I’m no expert in product management.

I’ve spent a lot (a lot) of time sitting in product management meetings and listening. My primary contribution to product management meetings?

  • Meeting #1: Me: “When are we scheduled to launch? What’s the date?”
  • Meeting #2-#999999: Me: “Does that affect the launch date? Is the launch date slipping?”

Yes, vital component. That’s me.

But it’s good. Because when I keep my trap shut, I actually listen, so I’ve managed to pick up a few things here and there.

And here’s where the worm begins to turn.

So, the other day, I’m staring off into space, thinking about product management, and this occurs to me: Everything is a product management problem.

How so? Well, let me outline some of the high points of product management.

  • Timeline / Road map / Lifecycle. Every product has one. The really good ones detail the life of the product, from conception through demise. On it, you can see every upgrade, every feature, every release, every date. Everything that will happen to that product. This is the plan. For the entire product. Everything that happens occurs here so that it can be seen in the context of the product life. And every change that is made is reflected here. All the new features, all the slips, all the last minute requests, all the executive force ins. Not only is interesting and vital to managing the process, it’s one hell of a document for the post mortem. And it’s the polar opposite of our next item.
  • Trade offs and compromises. This is the product manager’s preeminent skill. Everything in product management is a series of trade offs. When is that resource available to build that functionality? Regardless of when that functionality is built, when do we release it? What does the market want? What does the company want? What do we do to incorporate this last minute requirement? How do we retool based on the usability tests? Everything is a balancing act for the product manager. You can’t do everything at once. And you can’t do everything before launch. It’s a constant game of ready, fire, aim. What is attainable versus what is necessary.
  • Resource management. Once locked, loaded, and focused on target, how do we manage the resources at our disposal? Are we going to wedge in some additional functionality while we have engineering cycles? Are we going to bring in outside help to get us through this rough patch? Can we rely on a single engineer to bring everything to fruition? What if that person falls ill during QA? How much do I have to spend to get this done? Can I buy more time? Can I buy more resources? Do we have to build? Can we partner? Can we acquire?
  • Translation. The product manager is a Rosetta stone of sorts. Sitting somewhere between the business aspects of having a product and the labor required to bring that product to fruition. In high-tech, as an example, engineers don’t generally want to hear about the business reasons behind feature #479. They want to know the spec and they want to know what technology is at their disposal to create the feature to spec. Conversely, the CEO generally couldn’t really care less if you’ve created an AJAX implementation or used C#. S/he wants to know if the customer will be jumping for joy or throwing up all over it.

So taking those high-level points, shouldn’t we all be product managers for everything we’re doing? Shouldn’t we be product managing our startups? Product managing our investors? Product managing our employees? Product managing our product?

I mean, couldn’t your startup use some product management? A timeline? A life cycle? An attainable list of features and functions to be launched at specific intervals? What does version 3.5 of your startup include? Is it Windows, Mac OS, and Linux compatible? What mobile platforms do you support? Where are your feature/function gaps that could move your startup forward or doom it to inadequacy? What features do you want versus what functions does the business want? What happens when a competitor enters the market?

How’s your startup’s usability?

Think about it. Your startup will be better for it.

Marketing and New Product Development

Marketing management plays a key role in the new-product-development process along with the research and development department and other related departments.

New Products

The consulting firm Booz, Allen & Hamilton has identified six categories of new products in terms of their newness to the company and the marketplace.

New-to-the-world products (Product new to the company and the market)

New product lines: New products that allow a company to enter an established market for the first time (the product is new to the company not the market)

Additions to existing product lines: New products that supplement a company’s established products lines (package sizes, flavors, and so on)

Improvements and revisions of existing products: New products that provide improve performance or greater perceived value and replace existing product (Improvements in features and benefits of a product)

Repositionings: Existing products that are targeted to new markets or market segments (to be called a new product there must be some changes in the existing product to suit the new segments targeted).

Cost reductions: New products that provide similar performance at lower cost to the company.

Kotler says only 10% of all new products are truly innovative and new to the world.

New product development in various categories mentioned above is very important for any organization because existing products are vulnerable to changing consumer needs and tastes, new technologies, shortened product life cycles, and increased domestic and foreign competition.  Organizations have to be on the lookout for new products.

Factors That Contribute to Success in New Product Marketing

Madique and Zirger found the following factors:

1. Deep understanding of the customer needs.

2. High performance to cost ratio of the product

3. Being the early entrant into the market

4. Higher contribution margin

5. Larger amount of marketing expenditure

6. Strong top management support

7. Greater cross-functional teamwork among R&D, Engineering, Manufacturing, Purchasing, Marketing and Finance from the beginning

Effective Organizational Arrangements for New Product Development

An effective new product development organization starts with top management. The amount of money spent on R & D is an important top management decision related to new product development. Companies give the responsibility for new product development to product mangers, or new-product managers, or new-product committee, or new-product department, or new-product venture teams. In general product managers may not be able to devote adequate time to new products as they have to take care of existing products’ marketing and selling issues.

Managing the New Product Development Process

Eight stages are involved in the new product development process.

1. Idea generation

2. Idea screening

3. Concept development and testing

4. Marketing strategy development

5. Business analysis

6. Product development

7. Market testing

8. Commercialization

Idea Generation

A number of creative idea generating techniques can help individuals and groups generate idea. Some of them are:

  • Attribute listing
  • Forced relationships
  • Morphological analysis
  • Need/Problem identification
  • Brain storming
  • Synectics

Idea Screening

The purpose of screening is to drop poor ideas as early as possible and allow only promising ideas for further stage in the new product development process.

There is likelihood of two opposite types of errors occurring in this process. One, the drop error, results in dismissing a good idea. The other, the go-error, results in moving a poor idea forward.

Poor ideas result in product failures. Three types of product-marketing failures can be categorized: Absolute product failure loses money even on variable cost. Partial product failure recovers variable cost and some fixed cost. Relative product failure yields a profit, means it recovers variable cost and fixed cost, but the profitability is less than the company’s target rate of return.

Concept Development and Testing

A product concept is an elaborated version of the product idea and it is expressed in meaningful consumer terms so that consumer can visualize the product.

Concept testing involves an appropriate group of target consumers giving their reactions to the concept.

Will it Sell?

New Product Marketing Strategy Development

After the concept is finalized, marketing strategy needs to crystallized. At this stage the marketing strategy is expressed in three parts.

The first part: It describes the target market’s size, structure, and behavior. Product positioning is defined. The sales size, market share and profit goals are expressed.

The second part: The price and distribution strategy and the required marketing budget  for the first year are specified.

The third part: It describes marketing-mix strategy over time and evolution of sales and profit.

Business Analysis

At this stage, marketing department has finalized its market understanding and converted it into sales revenues and related marketing costs. The next stage is analysis of operating costs and profit analysis.

Product Development

If the business analysis clears the product, actual product development work is given to the research and development department

Test Marketing or Market Testing

High investment/high-risk products, where the chance of failure is high must be market tested. The cost of the market tests will be an insignificant percentage of the total project cost. Various types of market testing are:

Sales-wave research

Simulated test marketing

Controlled test marketing

Test Markets


Based on marketing, if the company decides  to go for the manufacture and sale of the product, capacity decisions are to be made. The timing of the launch, the geography of the initial launch, the niche market within the target market and how to launch the product become important decisions.

Consumer Adoption Process

Marketers need to understand the new product adoption process to build an effective strategy for developing market for the product. Adoption is an individual’s decision to become a regular user of a product. The adoption process is followed by loyalty process.

Stages in the adoption process

Rogers defines the innovation diffusion process as “the spread of a new idea from its source of invention or creation to its ultimate users or adopters.”

Adopters go through the following five stages:






New product marketer has to aim his effort at facilitating the movement of consumer who is an adopter of new product  through the five stages.



Philip Kotler, Marketing Management (Main text for revision and article)

Modesto A. Maidique and Billie JO Zirger, ” A Study of Success and Failure in Product Innovation: the Case of the U.S. Electronics Industry,” IEEE Transactions on Engineering Management, November 1984, pp. 192-203

See Bibliography also


Determinants of New Industrial Product Performance: A Strategic Reexamination of the Empirical Literature by GARY L. LILIEN AND EUNSANG, 1989….pdf

New Product Successes in Japanese Consumer Goods Market,

Hotaka Katahira, Makoto Mizuno, and Yoram Wind, 1994, Wharton School Working Paper

New Product Diffusion Models in Marketing: An Assessment of Two Approaches by Malcolm Wright and Don Charlett, Marketing Bulletin, 1995

Product Storyteller – Essential for Product Development

There’s an interesting question on Quora right now:

If you had to pick between an amazing product designer or an amazing engineer to build a new company around, which would you pick and why?

During any product development, the essence should always be targetted at ‘WHY’ than being or ‘How or What’.

If your execution focuses on the how and what of a product whereas in a world where consumers are inundated with choices, products that want to be noticed and adopted must be rooted in the why, in this case you are bound to face issues like scope creep, missed deadlines, overspent budgets, frustrated teams and, ultimately, confused users.

A product is more than an idea, it’s more than a website, and it’s more than a transaction or list of functionalities. A product should provide an experience or service that adds value to someone’s life through fulfilling a need or satisfying a desire. But who defines these values?

Let’s face this: The executive and the stakeholders would eventually define or identifies the idea…but after that who would be there in the organization to actually deliver the value to the customer? May be a Product Manager, Marketer, Technologist, or designer? Or perhaps…well…The Product Story Teller?

Who are the product storytellers? A bit of all these: matchmaker, marketer, technologist, and artist, the product storytellers ask questions, find answers, and figure out how to distill a vision or idea into a product story. They develop a plot, identify the people, and shape the product around the specific values it should offer consumers.

How critical a Product story teller can be?

The product storyteller facilitates collaboration and co-creation. Today, many companies have their product and marketing groups disconnected from each other.

Marketing decisions are often made at the executive level—much higher than where product decisions are made.

The result is that marketing tells one story, and the product tells a different story. In the end, consumers are left to put together the conflicting messages and try to determine why they should engage with the product.

A product storyteller should be positioned in the company to help break down the walls between all groups, facilitate the development of a single story, foster collaboration between groups, and ensure that every interaction a consumer has with a product or brand maps back to that story.

Share and evangelize: A common understanding of the product story allows a team to incubate a shared vision. This vision turns into passion, and people with both passion and vision are more likely to produce products that others want to use. Without a firm understanding of the why, the team risks becoming task focused, losing sight of the big picture, and deflating any sense of empowerment or excitement that once existed. When this happens, consumers and the team feel the effects.

In his book, A Whole New Mind: Why Right-Brainers Will Rule The Future, Daniel Pink explains that we’re in the “Conceptual Age” and that skills that were revered in the Industrial Age and Information Age are not as integral to where we are as a society today. Pink writes:

We’ve progressed from a society of farmers to a society of factory workers to a society of knowledge workers. And now we’re progressing yet again—to a society of creators and empathizers, of pattern recognizers and meaning makers. We’ve moved from an economy built on people’s backs to an economy built on people’s left-brains to what is emerging today: an economy and society built more and more on people’s right-brains.

The challenge today is that we face a shortage of storytellers because our current organizational structures and cultures are not optimized for the activities involved in storytelling, reason being : Ownership of product value,  communication disconnects, vision not in line with the original vision…

Marty Cagan, a product management and product strategy expert, addresses this issue in his book Inspired: How To Create Products That Customers Love. Cagan notes that there are two key responsibilities of the product manager: “assess product opportunities, and define the product to be built.”

The product storyteller should synthesize rather than analyzes, should see the big picture rather than becoming stuck in the details, and ensure that all product interactions and touchpoints form a cohesive and value-based consumer experience.

So whether you are at a small start up or a large organization, whether you are a founder, executive, technologist, designer, manager, or marketer, ask yourself this: do you know your product’s story? And perhaps more importantly, who creates your product story?

Courtesy : UXMagzaine

Time Management for Product Manager

In my day to day work, this is what I am being most disturbed about…how to manage my time, there are so many things to do and to prioritize is something, you go to learn, and learn it very fast, and not just prioritizing, but to effectively prioritize…

A normal day would be the one where you got calls with clients, being an advisory for other projects, managing your day-to-day ‘Not-Urgent’ – ‘Not-important’ things…this is where time management becomes so tough and so important for a product manager…here is the article which I think can help most of us who have been trying hard to ‘Effectively’ manage time…

Visit here.

Software Product Management – Trends

No. 1 – Portfolio Prioritisation

Are you working on the right things? The discipline of portfolio management isn’t new, but applying it in product organisations is much more recent. Product managers should ask themselves – what is the competition doing that I’m not? Are we prioritising our product portfolio so that our hottest products get to market more quickly?

Successful portfolio prioritisation is about several key factors. These include driving revenue into your organisation and measuring it through a variety of financial metrics; and aligning with the corporate and product strategy, ensuring that the priorities move you in the right direction for your particular company, product or product line. It’s also about securing the resources to deliver the product, and evaluating and measuring the tolerance to any risk involved. Most companies will also want to think about the impact of any activity on their brand, and whether the proposed strategy allows for successful leapfrogging of the competition.

The most recent factor that has come into play is sustainability. What will the impact be on the environment? Taking this into consideration, whilst evaluating the portfolio, is key.

And last, but of course not least, is the ultimate question – how will the product be received by our customers.

Software solutions, such as Planview Enterprise, include an investment analysis, which helps product managers to put in place a ‘what if’ scenario plan. This will evaluate product, features, projects and programmes and align these against the targets you’ve set, assessing whether you have the capacity to deliver. This functionality provides a product management team with the capability they need to drive products onto the market.

No 2 – Resource Management: How do I best utilise my people?

You must have the resources to execute, or you can’t deliver. One of the top three ‘pain points’ highlighted in the Planview benchmark study revealed earlier this year, was having too many projects for the resources available. It was clear from the results that companies wanted to be sure that their precious resources were aligned to products with the greatest strategic and financial returns. However, many respondents to the survey reported that they relied on manual approaches, such as spreadsheets to manage complex product portfolios.

The game changer, therefore is about three things: the first is strategic organisational planning, the second is ensuring that the resources for ongoing development are in place and the third is about dealing with the change that comes with all this planning.

Product managers have to consider how they are going to avoid resource bottlenecks, reduce risks, meet the launch date, eliminate resource cost over-runs, be proactive and respond to change in the organisation. If you find the best solution to deal with resource capacity planning at the outset you will be able to deliver on time and on budget.

No 3 – Agile Product Management: Why should I care?

‘Agile’ is not just a development concept. It is an approach that in product management should be used every single day in order to do the job better. There are a lot of agile tools available from velocity and burn down charts through to backlog for the product. Why should you care? It all comes down to delivering what customers want. That’s the job of product development and how developers are measured. Being able to have a clear view into how a project is developing and managing it at every stage is critical. Agile means being able to feedback to customers and involve them in the decisions and in the progress being made, and it provides a central point for all product ideas and backlogs, which is essential if a member of the product development team is away or uncontactable. Agile also helps you to be flexible to change and to meeting customer needs and bringing them into the agile circle. Agile is also increasingly helping companies with quality, enabling them to test a solution or product throughout the development process. This is also a major time-saver.

No 4 – Social Product Management: Are product managers going social?

Are product managers going social – they certainly are. Most product managers probably follow the blogs and tweets written by other product managers in their sector, and possibly even respond to points that they are making.

Product managers are embracing ‘social product management’ as quickly as any other industry is incorporating ‘social’. From a product management standpoint it is very important to see what competitors, customers, analysts and industry experts are saying through social media. It helps to keep you abreast of issues that are arising and ‘in the know’ when industry experts outline their predictions or the next big trend. And if your competition has a big announcement you will want to be the first to know about it. Being on top of product social management is critical in terms of how product managers do their jobs moving forward.

Aligned to this is social collaboration. Imagine you are in the middle of a big product development, and your team is spread across the world. How do you keep on top of what is going on? Through social collaboration, in the form of video or voice conferencing, and this is now possible by simply clicking on a name in your product management dashboard – that’s getting social.

No 5 – Product Management Analytics: What data do I need?

Probably the most important question that a product manager can ask is how can I show the key data that illustrates how my project is moving forward? In order to meet management demands for clarity and progress reports, product managers have to be able to instantly access a product backlog, ideally from one location.

Through the analytics, product managers can answer management questions relating to the relationship between innovation, enhancements and customer requirements, and queries about cost, capacity planning, offshore resources and the date that the product it is due to release. A product manager might also want to provide a revenue forecast.

One of the most popular metrics in the analytics function should be a roadmap. This can be based on the release date, the product, even by the market. All the key items should be in one location, and all the information should be in real-time, so the product manager can provide current data to management very quickly. The automated roadmap saves time and effort and allows you to pivot the data so that it can be seen by different criteria.

The additional benefit of real time analysis is that when you are thinking about your portfolio and trying to decide where the priorities lie, you have access to all the other relevant information such as what the competition is planning, your brand values, your resource capacity and factors relating to sustainability. If you want to make a change, you can do this in real time and the metrics will change instantly in one screen.

These are the current game-changers, the activities that will put your product management ahead, enabling you to automate at every stage from ideation all the way through to launch. These tactics remove unnecessary, time-consuming tasks, and deliver to you all the analytics and information you need to product manage effectively.

Product Management : Lessons to be learnt

Product Management, is a tough job. And eventually becomes tough when you are venturing in to an unknown domain. However if though carefully, and learned carefully, this can be the most beautiful, soul searching experience for anybody:

Underlined are the few learnings from “Software Product Failures”…and you need not be an MBA to learn this.

Here we go:

  • Creating a new market is difficult and risky.
  • Changing people’s working habits is hard.
  • Social factors can make or break a product. The end-users didn’t see anything in it for them.
  • If the end-users don’t like a product, they will find a way not to use it, even if their bosses appear to be enthusiastic about it.
  • Talk is cheap. Lots of people telling you how great your product is doesn’t mean much. You only really find out if your product is commercially viable when you start asking people to buy it.
Consider this:
DRAMA (Design RAtionale MAnagement) was a commercialization of a University prototype for recording the decision-making process during the design of complex and long-lived artefacts, for example nuclear reactors and chemical plants. By recording it in a structured database this information would still be available long after the original engineers had forgotten it, retired or been run over by buses.. There are lots of social factors that work against engineers wanting to record their design rationale, including:

  • The person taking the time to record the rationale probably isn’t the person getting the benefit from it.
  • Extra work for people who are already under a lot of time pressure.
  • It might make it easier for others to question decisions and hold companies and engineers accountable for mistakes.
  • Engineers may see giving away this knowledge as undermining their job security.
So NEVER ever disengage the social aspect of a product development.
Try this and you will never run out of steam:
  • Force yourself to get out and talk to people. Ask their advice. Almost everyone will help if you ask them for feedback.
  • Force yourself to cold call a few businesses in your target market.
  • Create a plan of how to market your product.
  • Try and use your product as much as possible as you build it.
  • Get out of your comfort zone from day one
  • Do not have the mind set that the day you release version 1.0 is the finish line, it’s the starting line, so hurry up and get there.
By far the most significant problem is:
  • lack of market research
  • lack of marketing

With the benefitof 20/20 hindsight it seems blindingly obvious that we should:

  • spend a few days researching if a product is commercially viable before we spend months or years creating it
  • put considerable effort into letting people know about the products we create.