[ Main page | About Your System | Knowledge Bases | Rule Traces | Demand Modelling | About Fuzzy Logic | The Importance of Explainability | Commercialising ]
This page discusses how to move from the Minimum Viable Prototype (MVP) to a full product.
Start by doing some self-examination and thinking about what enthuses you and holds your interest. Being an entrepreneur is hard work and often stressful, so it helps to have a product that you "believe in", whatever that means to you. I'm not trying to sound like a pop psychology article here, but I know this from my own experience and that of colleagues. It doesn't just hold in industry, by the way; students embarking on PhD research get the same advice. Three years of laboratory grind is hard to cope with when your emotions don't feel the point of it, even if you know intellectually that the research will benefit science.
You will need to temper this with knowledge of what can be sold to make you money. It's no good having a product that makes you glow with pride if you can't sell it. So look into the Canadian situation and find out what is likely to sell, and whether the market niche is fully occupied. At this stage, a very detailed evaluation might be too much, but it could be worth employing an industry consultant for, say, two to three weeks, to survey and report on the market.
Now bring your own knowledge to bear. You might have had to change your initial ideas in light of what the market seems to be, but let's assume that you now see a good opening for a product. How would you implement it? What does it need to know about dynamic pricing in general, about particular scenarios where DP is used, about market segmentation and time sensitivity, and so on? Here is where fuzzy rules can help, because you can try expressing your own knowledge about such factors in them. How easy is it, and what information might be lacking or need clarification? You can do this just as a paper exercise, but it may also be worth trying to write a set of rules that will run on a computer. Such an exercise invariably finds gaps and bugs in your knowledge, that would never be uncovered until you try to write them down in enough detail to be executed.
There are several approaches to dynamic pricing, and many different points of view towards it. It is worth getting an idea of what these are. It will help you find the right experts when you assemble a team (below), and it will help you talk to them and ensure that possible approaches have not been overlooked. So if you have the time, spend at least two weeks looking for research papers, commercial announcements, product literature, and online demonstrations. If you don't have the time, consider hiring a consultant to do this for you.
Research papers can be daunting, but there is an art to reading them: basically, skim the abstract to see what they wanted to achieve, then the conclusion to see what they actually did achieve, and then the introduction for motivation, background, and key terms. The introduction will often point to tutorials and survey articles. These can be invaluable in indicating the techniques that have been tried.
You now have a general idea about what your product will do, who will buy it, and how it will work: three of the Six Honest Serving Men. It's now time to add a fourth and decide who will build it. There are various ways to do this, and to structure the resulting team, if more than one person is involved. It's premature to list these, as many of them might not fit your situation. Instead, I'll finish by listing some of the questions that the developers will be asking themselves.
The MVP has demonstrated that one technology — fuzzy logic — works. The literature survey will have done the same, and also shown that there are alternative and hybrid approaches. Your market research will have shown, in broad outline, what the product is to do. We must now find out, in full detail, what users really want from it. It's not commercially sensible to guess at what's wanted, then waste ages coding a system that answers questions no-one wants the answer to. So we now need to think about what kind of person will use the system, and what they want to know.
This will probably be closely related to your sales strategy. What kinds of organisation do you think you can sell to? If you have close contacts with a particular industry sector, it might be good to begin there. One way to proceed might be to use an enhanced version of the MVP as a starter tool. Commission someone to enhance the MVP, then hire yourself out as a consultant. Find out what precisely the people you're consulting for want from it. Continue, gradually improving the MVP from consultation to consultation, until it seems good enough to be sold as a stand-alone product.
Another set of questions to answer is about hardware. If the program is to run locally rather than continuing over the web, on which computers and operating systems? Will you be ready to deal with all the versions of Windows, or (probably worse) all the varieties of Linux?
Requirements analysis is an important and often overlooked stage of software development, and one which means quite some time may elapse before coding begins.
Once you know what kinds of advice real users will want, modify the rulebase accordingly. (Here and below, I say "you", but it will often be your developers who I mean.) As well as adding new rules, it may be necessary to use machine learning to tweak existing ones, by adjusting the fuzzy sets they use. It may also turn out that fuzzy logic is not the best tool, or at least needs to be combined with another. Your literature survey will help guide you here. Also, any reputable developer will be able to do their own survey, rather than sticking blindly to a method that is sub-optimal. Do allow plenty of time in your development plan for this.
Software experts generally recommend leaving this until near the end, when you know exactly what needs to be input and output.
And also write or find tools for automatic testing. Run the entire suite of test cases every time you update the software, including every time you fix a bug.
Note: in practice, you'll hit bugs as soon as coding begins. So superimposed on these stages will be a continuous cycle of finding bugs, fixing them, and testing.
Also note: different developers have different preferences about how to structure development. I'm describing a classic model of software development which has been around since at least the 1960s, but there are others. For example, "agile development" often compresses requirements and coding and testing into a single step, then repeats this step again and again as a cycle of small incremental improvements, each one geared at the specific needs of a particular customer.
You will need at least a tutorial for novices, and a reference manual. These need to be available both as web pages and as books or manuals.
Recruit as many users as you can who have never used the system. Give them the documentation, and see how they do. Note and fix bugs, both in the software and the documentation.
Around this time, you'll be ready to send out beta-test versions and to start giving demonstrations.
And hopefully not much later will come the PRODUCT LAUNCH!