From Vision to Reality
Introduction
Have you ever had a vision about an application but when you ended up creating something the reality isn’t quite what you expected it to be?
Vision vs Reality
It can be very hard to turn your thoughts onto paper then once you go through several layers you can end up in a game of Chinese whispers where the end results is very different to how you envisaged it. It’s difficult to get the reality to live up to the vision.
I’ve been asked by many fellow clinicians to do this blog even though I don’t think I’m still qualified. There is still lots around this specialised area of healthcare which I haven’t done and know little about. This blog is just my experience which I hope others will find useful. If anything I hope I’m showing there is much more to IT development in the corporate healthcare sector to a visage we have of releasing an application then going back to your day job.
However looking back I can say that there is much more to the story than just the fantasy of transmitting your thought to code, waiting for the money to rake in and exiting left on a tropical beach with an early retirement which just doesn’t happen often. You have to love what you do and be committed and consistent all the way through the journey.
The Journey
I’ve also realised there is no destination until you truly exit so there really is no real good time for this until you consciously choose there to be. There is only the journey and we choose when to leave rather than there being an endpoint. Think of a train ride with no endpoint but not a circular track, a train with endless stops and no real end destination. When we want out we wait for the next stop and go onto the platform and exit. The question is if you are prepared to start the engine and go on the ride?
This is a practical Blog for those fellow clinicians who maybe have ideas or a small prototype who want to go to the next level in Healthcare IT. There are other avenues to help you take you up the ladder. 2 examples in my area are the following so please look them up. However, as with other aspects of this market, you are not alone and there is competition in applying for these grants or apprenticeships.
Home - Health Innovation Network - Gives grants and connections to aid exposure of local innovations to be spread locally.
Accelerator - DigitalHealth.London - Helps SMEs to take their idea into Healthcare by giving them an NHS Navigator to take them and help them manage the pitfalls which potentially could be encountered.
I personally have got to where I am with no external investment just from directors own money but I’m not necessarily saying that is a good idea.
There is a concept called the infinite game which was coined by Simon Sinek which I think is a brilliant analogy in short-sightedness vs long term game players. He summarises it much better than I could in this video
In essence, we need to look more at the infinite game for any business and look at improving ourselves to be better rather than worry and change to beat others, but more importantly, always be moving forward and not sit and be happy with what we have.
Vision for your self
Before you even start you have to have some idea about where you want to go with your vision which will depend upon time commitment, effort and resource.
I used to think that sheer brute knowledge in development can force you into a position where you don’t need cash but to be honest this is just not the case. If you want to move at any pace and still keep your day job the bottom line is you need a funding injection.
I saw this simple graph once and it really hit home around where individuals want to be when it comes to growing their business and it boils down to 3 types of risk takers
1. Those that want all in and want to be millionaires. They invest or convince others to invest in an idea at great cost hoping their idea will stick and they will float and go to that beach. The rewards could be substantial but if you crash you crash hard so this is very much a high-risk high reward avenue.
2. Those that constantly grow their business with time not interested in going public but would like something more out of it in the long run. They normally invest their own money into their venture hoping it will sell to give them a return and tend not to give much of the company away initally.
3. Those who just want to pay for their holiday and reach a certain level and stop happy with the income they have. These are the lowest risk-takers but in the end, their input is less so they can spend more time doing other activities they like.
Growth Wish
The other aspect to really appreciate is that it’s really true when they say success doesn’t happen overnight. A friend once told me it’s like a bamboo tree. After years of nurturing and growing little seeds, you get nothing. Then one day the seeds grow 80 feet in 6 weeks.
Be as large as what you want to be and what you are prepared to sacrifice if do you really want to give up your day job for it. I’ve known plenty of successful clinicians who have given up their day job so this isn’t a rhetorical question.
So in summary
Keep the growth as a lifestyle to medium if you want to keep your day job
Look to sacrifice more if you are looking at larger external investment with a higher risk and potentially higher reward.
You need to decide how much time are you willing to give up for this cause.
Intellectual property and trade-offs
IP
Intellectual property is so important that it deserves a whole section in itself. As with most things in life it starts off with an idea. Please don’t be frightened of telling others about your idea. Ideas are a dime a dozen and very few ideas actually take root and turn into fully blown products. You know what they say 1% inspiration 99% perspiration.
Keep your idea simple and try to find a niche initially and be very specific about your audience and your scope. Know in yourself that you can’t replace Emis and don’t even try.
At the same time be meticulous about exactly what you want but more importantly the steps you need to take on how to get to the first release. I’ve frequently heard from colleagues that they want to digitise this and that with no thought of how. You can’t make an app from behind your cigar on the top floor of a multistory office in the middle of the Shard and shout “I want to create the best app ever” and just expect it to be done. It’s easy to express an emotion about an application (eg I want an intuitive application) but much harder to create it.
You can be top down and start off with screenshots or mocks of your final version or start off with what data you require and work bottom up but have a white paper which explains as much as you can to more technical people.
IP Flows
IP in Simple Terms
In simple terms your IP is how you manipulate data from various sources into your mentioned output.
Where to get the data from?
Drilling down into more detail where do you get the data from? There are several sources as listed below
Patient Data
From Clinical System via API agreement
From Patients
External sources eg BNF dictionaries, NICE Guidance, Snomed DataSources
Bespoke Data from Local guidelines eg Surgery
The above diagram then looks something like this
Types of Inputs
As you can see the concept is simple but the complexity is how you automate the data feeds into your system, how you manipulate the data and how you then present that to the user.
Vehicle for your IP.
You could argue as GPs were are the equavalent of consultancy but for healthcare. We impart our IP to patients in exchange for a salary given by the government as a monopolised business
The IP you create when making your product needs to be injected somewhere if you are serious about this industry and the best place is a limited company mainly owned by yourself. I say mainly as you should offer shares to others who buy into the idea to share the IP which is now company based rather than individual-based. I don’t know anyone who has built up a business without a vehicle and some form of governance structure within so don’t think this can be done without it. You need a business, you need to inject your IP into this business to give it a defined quantity and you need to involve a solicitor and bank manager to set up your company
I can’t stress to you how important this point is and it’s something you only realise after you’ve passed the point of no return. If you are prototyping you have to choose where you put your IP and if you are converting this into a product, the NHS needs you to have a legal entity with the correct structure in place in order to accredit you. After you get your prototype up and running the next best course is to get a grant or invest your own money and gather interest locally to build up from there. To be honest, NHS bodies hardly ever give money to untried or untested companies without the backing of larger companies. You have to wait until you are large enough or have been in the industry for long enough to be able for NHS bodies to trust you or sell to individual practices with the hope that word of mouth will spread. Alternatively starting local with close connections you’ve created over the years can help you build up.
Another option is to create an independent NHS tech body to inject your IP into and build up from there as an in house entity within a symbiotic relationship with your local NHS non-tech body. From here you can branch-off and sell to the rest of the NHS with the same concept you have tried and tested locally.
By the way it is extremely difficult to patent an application so don’t try. It has to be truly innovative and new and this is extremely difficult to achieve and most applications are an evolution of apps from other industries massaged into healthcare or an iteration on and existing product design or concept.
TradeOffs
As you probably know or soon will know there are so many different options to chose from in IT and it’s for good reason. No shoe size truly fits otherwise everyone would be developing the same way with the same language and the same frameworks. There are tradeoffs with one type of solution probably being better than another at some expense and it’s a matter of what you can live without the most rather than what you think is better!
With this in mind there should be several factors involved with making decisions around what route you want to take and what trade offs you are prepared to make
Who is your market?
patients - server side but don’t necessarily need patient identifiable data
clinicians - if sharing clinical data on a server need to go through IG
operational or management - might have server side IG issues but depends on your scope
TradeOff - Are you happy to deal with anonymised data or do you want to go through the IG issues to deal with patient identifiable data which will give you greater functionality
Familarity vs innovation.
There is a unwritten rule in UX design that all roads lead to Amazon. They are the kings of how we understand how a web page design should be. Other web applications emulate this not because they are lazy but because the familiarity of the way the page is laid out means that visitors instantly know how to navigate their way through because everyone knows Amazon.
The flip side of this is that you don’t innovate if you stay cautious. When designing the screens bear this trade off in mind.
Web or Desktop?
Most of the direction of travel is Web based currently to be honest. Web site development is the holy grail of development as you have an environment where you deploy once to the server and instantly everyone has the latest version with no deployment issues. Having a central repository means the code base is instantly maintainable and scalable especially when moving more to cloud development.
However you look at it though, you are never going to get close to the richness of Desktop API which holds a more direct connection to the operating system so gives you better options in terms of speed and UI
Can have hybrid system which offers both. Indeed EMIS is a sort of fat client at the moment where it is a deployed app but there is a database which is held on a Web Server. One issue with this solution though is you have to maintain both the desktop and the Web Server which is the worst of both world scenario!
What Environment?
Also there is no ideal development environment or ideal deployment method or ideal language. Each have their pros and cons and it depends a lot on personal preference as well as what you think is right for the scenario you want to achieve. Having said that please stay clear of Excel and vba for production. It’s just not scalable.
IG issues and Hosting a solultion
One question I’m sure you want to ask is where to start if you want patient data on the Web. As you can imagine this is a huge IG issue so there have to be robust mechanisms in mind to manage this or we will have data breaches everywhere.
You can start off here https://digital.nhs.uk/services/health-and-social-care-network
For Patient Facing Services and also getting API access for business apps dealing with patient data you will need to have separate contracts with each supplier or go through IM1 Paring Integration
IM1 Pairing integration - NHS Digital
The advice of others is to contract and outsource this out to companies who know how to go through these processes and will have access to UK cloud base services which you will need in order to manage the data and know far more than you around how to do this.
Be prepared for the Journey
Ah the Journey and be prepared for a bumpy ride. This sections just comprises of thoughts which are important but don’t fit in other sections. Think of each point as items to take into consideration during your journey
More than just the Application…
Sorry for those who used to do NHS hack days but I found them to be a false economy. For the one I attended over 95% of ideas generated were simply already in production so this ended up being more of a showcase rather than just seeing what you can create in the weekend you had available.
The 1st release is only just about 5%-40% of the total lifetime of a product depending on how you grow your product and add additional features so an idea that generates a spark soon dies off as clinicians realise just how much it takes to go to the next level.
“Great software isn’t built. Great software is grown” Bill de hÓra chief architect with NewBay Software
There should be better ways to cultivate the richness of ideas we have in healthcare but it goes to show that development is more than just the first release.
Find the time
You have to find the time and you have to persist with your endeavour if you want to get anywhere. As I assume you are also practising this means creating time during the day by working part-time or evening and weekends.
There is also only so much you can do with your time which you have to divide between coding, implementing business logic, training, promoting, seeing patients and spending time with your family!
Products don’t sell themselves.
If you have time see video from TechLand (11) Why I’m so good at coding. - YouTube
As stated above products don’t sell themselves. You can have the best product out there which does something which is much more clever than anyone else’s but if no one knows about it no one cares. So make sure you market your product well and keep it simple for the audience (something I fail to do!)
Going Solo and your day job
Don’t do it alone even though you think you can. Try to build a team which is good at each aspect of the business rather than several people who are competing for the same spot.
I get asked this a lot and each is different depending on your situation; should you give up your day job? Initially, at the start of your journey, I’d say definitely not. The Healthcare IT industry is very conservative and it takes time to grow and be in a position to be able to leave at least part of your day job. But whatever you do enjoy the journey and enjoy what you do.
Hobbyist vs professional
Are you a hobbyist or professional when you start your venture. There is an objective answer and a subjective answer.
To me, the objective answer is when you get your first paycheck and have a company you are deriving payment from you have moved to be a professional in your chosen sub industry.
The subjective answer is that the question is irrelevant and it’s less about how you think but more about how others perceive you. Once you have more of an infrastructure in your business to support, train and market to, others will consider you and take your business seriously.
Product or services
Services, services, services. In this industry don’t even think about creating an off the shelf product which sells itself and maintains itself. One which you can just release and forget. This isn’t a video game and you need to constantly evolve it, learn from your mistakes, keep it up to date, support it and constantly train new staff on it.
What does scalable mean?
We get asked this question a lot from people who are looking for an opportunity to invest or just want to ask the question and see how you squirm. A scalable product is one where you can provide a similar service to one user up to 1,000s of users and it’s a total misnomer when you start off. Just get what you can off the ground and see if has legs. Don’t worry about if it will work when 1,000 when the first 10 you market it to don’t like it.
It’s something you normally think about after you’ve got over the hurdle of keeping your business alive but a few key initial seeds which will help are
reduce the number of dependencies you have with your application (by dependences I mean reliance on other products for your product to work)
think when you make your product if you can push everything to the cloud and how this would work. As a rule of thumb cloud products are scalable by default.
Don’t rely on frameworks with no flexibility. VBA, excel, macros applications are not scalable. You need a reliable data source with an API that will work if there is one user or thousands of users. In other words only allow access of the data source through automated methods.
How much money do you need?
The aim is more about how much do you need to take the product to market to generate sales rather than how much you need for the product in it’s entirely which in essence is where to walk a thin tight rope on decision making.
Once you have enough sales you can fund further development and to keep the company going, pay off your investment and provide a service with training support and debugging.
There then becomes a question on how much are you happy to keep and how much do you need to invest back in to the company to drive it forward.
Apologies for not getting to the point. So how much do you actually need? This depends so much on
what the skill set of your existing company is (who in essence are providing resource in the hope they will get a return for the shares they have)
the complexity of your application
server and infrastructure cost
dependencies on the application which you have to pay for
contracts with other companies who take a slice of your revenue in exchange for the service they provide or data end points you need
how much you plan to sell the application for to recoop your investment
whether you decide to outsource your work (more expensive in general but less hassle) or employ people in house (less expensive but can be a lot of overhead around employment side of the business)
Apologies yet again for still not getting to the point. If I were pushed I’d say
upto £20k for a small sized application or prototype
about £40-60k for a medium sized application
over £100k+ for a medium-large size application
£100ks for large size
Naturally you can cut these values if you have in house developers or manage to get something out yourself.
There is an unwritten rule to double the cost and double the time from the plan you pick and this is definitely true so some extent so bear this in mind.
As you start ploughing into your budget it then gets to be a judgement call on when to release as running out of money is a common reason to release more often than not. we sometimes release too early in order to be able to kickstart the revenue generation. Release too early and you have a buggy mess with no functionality and just isn’t attractive to users, release too late and you suck up your funds and have a mammoth task to then recoup your losses.
There is no right path it’s always a trade off between options and which one is the best one for you. See this diagram
Juggling Balls
You are juggling between time taken to complete, how much development time you have and the scope or how big your application will be. The money in the middle is normally the fixed element
for example, you find the time is dragging on so you need to reduce the scope if you have a given budget. Alternatively you want to increase the scope but this will require more resources or will take up more time.
Ultimately adding more money resets the system and allows you to
increase resources
increase scope
reduce the time taken
Thus it’s so important to understand the scope for release one to allow you to be in budget but have enough functionality to sell then grow from there.
If you are contracting out you can pay developers an hourly rate or a fixed rate for the agreed scope. Both have pros and cons and relies a lot of trust. A good half way house is to have a fixed rate but give penalties if milestones are not achieved by within a certain timeframe.
Be Realistic, be persistent and don’t procrastinate
JFDI! (google this if you don’t know what it means) If you think the idea is cool just do it but spend as little time and money as you can to prove that it works first. This is how we started with PatientLeaf to test the UI to see if it work and if there was a potential user base who would like it. I still don’t think we’ve got it right with PatientLeaf to keep all kinds of users happy but we will get there.
Which goes onto my next point which is to be persistent
Ambition is the path to success. Persistence is the vehicle you arrive in. ~ Bill Bradley, Starbucks Corporate Director.
Success is not the absence of failure; it’s the persistence through failure. ~ Aisha Tyler, Broadcaster and Actor
If you get criticism, don’t ignore it: take it on the chin and try to learn from it. You have to understand why people don’t like your app and if you believe they have a point, fix your app. At the moment the an area I have with PatientLeaf is that it’s too overwhelming although to be fair what I’m showing is complex. A lot of clinicians love this so I am also finding ways to manage this and keep all types of users engaged.
Start off with something small and build up in a direction you want to go in. Don’t try to build Rome in a day and go at a pace that you can realistically achieve which leads to my next point which is to find a niche and focus on this. Please don’t try to reinvent EMIS but do try to complement aspects of it.
In summary don’t give up!
Should you Code?
The bigger question is if you need to code and, to be honest, I’m very much split on this debate which I know has been going on for a little while.
The argument against coding
The dilemma we face as doctors is that if we want to stay as doctors we don’t have much spare time and as development takes so long you are using up the precious free time you have left to code when you should be working on other important facets of your business. The end result is that you take too long to get something up and running if you want to do it yourself or just lose interest.
Also to be honest it’s the developer’s job to take your mess of a concept and formulate it into 1’s and 0’s and the key to success is more to find a good developer who can take abstract ideas and understand what is in your brain to convert it to digital rather than spend the time to do it yourself.
On the other side of the argument is
If you know how to code you know how to create worlds so can establish yourself in a position of real power in creating or directing the creation of your products and the chance of success is higher as you understand the limitations and capabilities of your created engine. But it takes a lot of time and a lot of effort to get to this stage.
A lot of projects start off with prototypes which are ugly vertical snapshots to prove the concept you have that your idea will work in the proposed setting. Prototypes normally have pre-populated data rather than automated feeds and just show and prove how the product would work in the real environment. This is important for most projects as you need to dip your toes into the vision to see if your application will have the desired outcome before jumping in at the deep end. A very low-risk way of starting off is to prototype yourself rather than charging a developer and from this prototype get investors or others who can share your vision involved to help you commercialise it. It’s always easier selling a physical snapshot that others can see as opposed to an idea.
Sitting right in the middle are doctors who don’t know how to code but are good enough to be able to use tools to inject IP into an existing product to make it desirable for others to buy and off load the risk too. Ardens and Primary Care IT are examples of such individuals
Whether you code or not there is a specific skill set you need to have to be successful and I think most doctors have this. That is the ability to break big jobs up into smaller bite-size chunks. I say most doctors know this as this what we had to do for years on understanding the huge topic of medicine the subject and being able to break it down to understand each aspect of it. Coding is no different.
How Big Do you want to be?
There is also a question on how big you want to be which ties in to the start of this blog
For larger projects gets clinicians to code is a very inefficient use of their time
For smaller projects, you need to have a larger skillset and if you have your own small business you should be able to fill the shoes of every part of that business. You can mitigate this by giving the developer a share in the company to tie them down. Otherwise, this represents a reliance you can do without so being able to code then becomes more advantageous if for example you lose a developer and have to maintain code while finding a new one.
There is another solution which is to go Open Source which has several advantages as you don’t really need a legal entity and if you get a few like-minded individuals you can all work together on a common goal more focused on the vision rather than worrying about other aspects of the business. But if you are giving your code for free how can you pay your bills? Well, the hope is that by being free it will increase penetration which in turn will help your standing and you can offer consultancy in its implementation within the NHS. I would love this concept to work but I don’t think it does at the moment as for all intents and purposes IT is free for NHS staff or perceived that way. Costs are abstracted out from the user and paid for by the taxpayer via contracts and procurements. So going open source and not going open source has little meaning to the user (not the commissioner). Where I think there have been success stories are in large movements such as OpenEHR and some US movements eg Mirth Connect which is now called NextGen but these are huge and have taken a long time to grow. Conversely, open source happens when a company is really big and wants just open-source to grow its community. Microsoft is a good example of this. From a commissioners point of view, I think the problem with open source is the risk. Why would they look for an open-source solution when a company offers them a proprietary solution albeit at a more expensive rate but at a perceived lower risk to them. Ironically though mature open source solutions tend to be more robust as they’ve had a whole community looking over them rather than a smaller development team
For Wanabe Coders
If you really want to code this will start you off in your direction of travel but bear in mind if you haven’t done much before it’s a very difficult mountain to climb and maintain your day job and sanity. There is this 10,000 hours of practice. It’s a common rule of thumb, popularized by Malcom Gladwell in his bestseller Outliers: The Story of Success. More recently it’s not as popular as a concept but that aside 10,000 with a practical time investment for doctors at consistent 3 hours a day is about 10 years so be prepared.
So where do you start? Well it all depends on what you want to do as your final end point. It’s similar to medicine where we qualify but don’t decide on specialisation until later but in this case it would be good to know as you just don’t have the time to learn everything.
Having said that there are basic core concepts which are across everything in software development which everyone needs to be aware of (eg object orientated programming and to an extent relational database concepts) but bear in mind which cog you want to be in the larger engine. Very early on I wanted my main focus to be on Line of Business applications within GP Surgeries and have focused my learning based on this core philosophy.
Development 101
You sometimes hear this term “I’m a full stack developer” but what does that mean?
Almost all applications have data following layers of separation.
There are 2 ways of looking at this
3 Tier
This is a principal more for an enterprise solution where you have 3 distinct physical locations where the data is stored or presented.
The lines between each location represent the internet or networks which move secure packets to and fro depending on the need. A term we use when transferring data in the pipe is a DTO or Data Transferable Object with Json (a way of structuring data in text files) nowadays being the preferred format of transfer.
There is another concept is around how applications at a smaller scale are organised which is similar in some ways
3 Layers
In this example, you are moving data up to present information to the user and back down to a persistent data source with your programming language as the glue to connect both together but this can happen on the same machine .
Full-stack is normally associated with this concept so if you want to code you need to think about where you would fit in.
Which language you want to learn depends on where you fit into the “Stack”. Personally, I think Doctors should be more front end as the nuances of the User Interface requires a lot of knowledge in the field.
Which language should you choose
To be honest, nowadays it doesn’t really matter. More recently with Mono, .net is open to non-Microsoft platforms and JetBrains offers amazing Java environments on Microsoft platforms. I’m .net C# but that not really by design. It’s just something I’ve learnt from a young age which I’ve carried on and I haven’t the time to learn new technologies.
How to Learn
There is so many resources out there its so difficult to recommend any and everyone will have a different opinion. A few options are
Attend a Course or formal degree.
To be honest, if you are really serious you need to attend a course or go for a formal software development postgraduate degree. The reason for this is that it focuses your mind and gives you a goal and formalises your thought processes and gives you structure. It will also help you with your self-motivation as it forces you to work!
Subscription Level Web Sites
These are a few sites I’ve used and have had good feedback from. They help you to work through at your own pace and if you are self-motivated enough will not only help you once you have got to a certain level but will help you go to more advanced topics. I subscribe to Pluralsight which is more .net focused but has other areas of interest too. Others include Codecademy (for Python) and Code with Mosh who I found such a good teacher of concepts. Otherwise, there are a myriad of YouTube Videos.
General Coding Advice
A few points which helped me on the road
Get a good Patching Software if you are planning for desktop development
Learn about GIt and use it, regularly. I’ve recently been introduced to GitKraken which I’m so impressed with
Decouple the Code Separate the Data from the application. Look into interfaces between layers and look into onion architectures
Reduce your software dependencies ie what external applications you need to depend upon to get your app working
Automate data transfers into the application via an API rather than rely on users to do this
Do not use the GUI of another application for example AutoKey as it’s not a reliable way of obtaining data. The other application developer can just make a subtle change to the GUI and it will make your application fall apart for you
Don’t use media that you can’t automatically deploy and patch up. You need to avoid manual updates. Although Excel VBA spreadsheets can be ok for prototyping you can’t really use them for larger-scale applications.
For non Coders
This is probably simpler but it’s important to get a developer and define your boundaries and be very meticulous about your vision with the ability to break everything down to its most atomic level.
The Business Logic is your jam which is the layer between the database(what you store)and the GUI (what you see).
Get the developers to create tools for you to use this as your playground
Product Life Cycle
Just to give you an idea that it’s just not creating code this is a brief timeline of what is expected from you in your journey
The Pitch
Selling the vision without showing anything but asking others around the to buy into your idea.
Prototypes would sit here
The Investment
As stated you cannot develop at pace without investment be it from your dividends, a loan, external source. There is a risk if you invest yourself but a potentially higher return if you can manage not to get external investment. With external investment though might also come expertise in the area which will help you be a success.
The Dev
Working with developer to create the first release
The First Release
1st build is very rarely good. You need to persevere and iterate and learn from mistakes. Unless you are very lucky you will need to change the product to adapt to what everyone wants rather than what you want.
So when to release your first version? The hardest question I’ve ever had to face and still get it wrong
The Market
The concept of the product selling itself is a misnomer. Products in healthcare don’t sell themselves and marketing to me is one of the most important aspects as highlighted above.
You need a way of promoting new features so they don’t disappear in the app and aren’t used. A Spike of interest occur when this happens which helps the marketing
The Support
Users need a port of call to do reinstalls, crashes, password issues. These require telephone and remote support.
The Training
Very few products don’t require training unless they are really simple and fill a specific niche. If you don’t train users won’t use it to its fullest capability and might now renew when the time is up
The Iteration
Further research and development is required to move forward.
You always gain more interest with each iteration. After each release interest wanes until you develop a new feature that you can promote which will help sales. Hence you need to continually develop your product and don’t sit on your laurels.
From feedback and your own roadmap, you develop further then go back to The First Release section above. Rinse and repeat
Summary
When I got my Master’s degree Mark Shuttleworth who is the creator of Ubuntu gave a passionate keynote lecture. He spoke in terms of not chasing after success, just work hard in what you do and if you do well, success will follow you. I think at the moment I’m far from successful but that doesn’t stop me from enjoying what I do.
And for those who haven’t been dissuaded by the content of this blog or have managed to read to the end, I have a message for you.