I personally love the MVP approach to applications and it is how I build all my personal tools – build just the essentials necessary to get the job done.    What I have found out that while that works great for personal consumption it has different challenges and expectations when you apply it to commercialized tools.
If your not familiar, MVP the acronym for Minimum Viable Product is the idea to develop enough of an application to test the concept and see if anyone would buy it before you completely bake it. Â Â What are the minimum features and functions necessary for others to want to adopt it? Â I think this is a good approach to application and product development but comes with challenges and frustrations for both the developer and the user.
The primary benefit to the developer is it can prevent a distraction and waste of resources on something that may not take off as well as show you a different application of the solution that you may not have considered though customer feedback.
For the past 4 years I have been building a Keyword Management System and many of the features came from users who wanted something more and I used that feedback to expand and adapt the application. Â That experience and that of these other new tools have shown me that the customer is not always right and that a lot of care and feeding needs to go into a MVP process to help educate and nurture the growth of the application. Â Many of the experiences I detail below are a given but some of the other feedback and experiences were totally unexpected.
Different Approach to Similar Problems
One thing that is certain is that I often have a different approach to SEO challenges than many other consultants in the industry. Â I have learned over the years to find the root cause of poor performance based on a systems failure diagnosis. Â To do this I have had to build a few custom tools to serve these purposes. There are four tools that I have been working on as part of this project where a few months ago at after a session on Diagnosing SEO Performance Issues many asked if they could license a few of these so I took the time to make them available. Â This is where the fun began.
A big thing for developers to overcome is your opinion of a features importance to the potential customer. The problem or needed that triggered the need for the tool creation initially for me may not be the same importance of the potential target market.  That is a hard thing to overcome as you assume that if you have this problem others must as well. This is a key set of questions you have to ask to help you navigate the process
1. Why has no one else created this? There is no need for it as it is new problem? or not big enough to need a tool? or workarounds are fine?
2. Is there a complication that makes it hard to create/deploy?
Frame of Reference
For the original requester who was in the conference session and understood what the tool did and why I created it so they were willing to log on and use it. Others that I thought might find it useful and sent them a email suggesting they give it a try did not have the same response. I found them to be the most confused on why they would use such a tool.   I found I had to give them a frame of reference for it.  For example, my redirect checker I had to tell them it was like Screaming Frog but goes farther or had this application.  A few I sent to them after they posted a problem or frustration on Facebook or as a comment to a SEO article.  Then I had to explain why it went farther and could augment other tools.
Audience Applicability & Feature Importance
Along with frame of reference, was the potential users lack of experience with the problem the tool would be a solution for. Â For many users, they had never encountered the types of problems with their clients where they would need the tool and that explained why they could not understand the need for it. Â These are the people that are not perfect customers.
Diminished Urgency
That moment of epiphany that they realize this is a cool tool and they need it is critical to capture people.  For example, after the diagnostic presentation when I had multiple people engaged who wanted access to it. However, I did not want them to see all my client projects so it took about a week for me to add the access and account segmentation which lost valuable time.  In the week that followed, when I emailed people the access nearly half did not try it.  They had lost that urgency they felt in the moment at the event.  That epiphany at the event was an emotional needs connection that you cannot replicate later.
Now if I release a tool I have a link and sign in for it immediately to catch and keep their attention. Â In my own tests I found that it often takes someone 5 to 7 days to log in once they have access and more than 3/4 of the people who ask for access never login unless they are directly prompted. Â For my HREF Builder tool only 4 of 10 people who specially asked for access ever logged in and ironically, 2 of the people review tools and one writes primary about international search never logged into the application
Can’t x do the same thing?
 In half the cases where I had asked people to take a look vs. those who reached out to me this was the response.  The redirect checker was was the one that I got the most push back on as they assumed it did the same as Screaming Frog or URI Valet. Both do some functions but not all of them and not at the scale.  On the same note, it is often good to associate it with another tool that they are familiar with as that gives them a frame of reference.  I learned you have to articulate the differences in tools and ensure that they can easily understand why they would use one over another or with another.
The Easy Button
Most people don’t read directions nor want to think about how to use a tool.   The is why the UX and UI must be good for those initial users.  Most won’t read directions.  For example, in my HREFBuilder tool – we did not have time to code in a pull down selector we created a table.  We asked the users to go to the table, find your URL combination and then copy the appropriate regex and paste it into the tool.  In nearly every case the initial users thought this was too hard to use on first attempt.   For me coding some other functions were more important as I had no problem copying and pasting but even people on my team said – “Can you Make it Visual†or can you just detect what my site has.
 To get early adoption you do need to simplify the onboarding and set up in order to not create that image of difficulty that may taint their willingness to try it in the future.
Missing Features
This is the most frustrating outcome sharing a new tool and also the most welcome outcome as it fills the holes and can help make a OK tool great. However, a key thing try to communicate to the potential user is why it is the way it is. For example, I failed to tell the initial people that these were my personal tools, built to my needs and specifications, and I was/am the only user and that I had not intended them for external consumption.
Second, I am 100% function over appearance – I don’t care how things look as long as they are functional.  To make the first version ready for regular use I had to adjust the original interface as they were not that intuitive and also create a login management function to separate users and their data. That was a decent investment that ensured user privacy. I did not change outputs or some of the key set up functions.
While you tell people what you are giving them access to is a beta with limited features many expect a fully baked out tool before they try it and may getting frustrated you did not have features.   It is interesting on how people look past the basic function and come up with advanced features. This can be very helpful to set the direction of the tool but can also be a distraction.  As most of these tools solved a specific problem the suggestions I received I may never had considered. This is exactly why you have to be patient and nurture the process and get actual users to try it as they often have insights you do not.
However, you need to still expect them to want more features that it has especially if you have set any preliminary pricing as that is the value they will attribute to the pricing and not associate it to a final product.
A note on features, in my keyword management tool we have added a lot of features asked by users and when we monitor use they never use the very feature they wanted.
I always try to challenge the need for the additional feature and what would it gain. Â Not to be critical but to help prioritize as well as try to get a better understating of what is really needed and why. Â This often offends people as you are questioning their intelligence or approach which is not the case but just clarification.
Pricing Issues
Many of the people wanted to know final post beta pricing before investing time in testing the tool. Â I can understand that if it becomes to expensive they could not afford it and would better not know there is such a tool. Â Others want featureless pricing with all the features and/or want pricing consistent with other non-related tools. Â For example, the HREF Builder tool we have adjusted pricing a few times and have developed custom pricing for power users.
One conversation I had with a potential user who felt that the pricing was to high. Â They offered 3 reasons for their comment.
1 – Price relative to other industry tools – they referenced Moz (does not do anything like this) and Screaming Frog (annual license fee but doe snot do this action)
2 – Lack of tracking and reporting features (there is nothing to report but apparently any month/month SAAS product must have tracking)
3 – Not intuitive or completely user friendly (While no connection to price, they wanted to pay less for a work in progress application)
When I challenged them on the labor cost to do it manually they agreed this would be more efficient but felt that adding a cost on their side they could not pass on to the client was a challenge.
They indicated that it takes them 20 to 30 hours to do it manually and they can bill the time to the client. Â Asking about charging a flat fee or using that time to something more beneficial to the client they did not want to think of it that was.
Change Averse
People hate to try new things and like to use tools that they have been using even if they are more complicated. Â I get a lot of people that ask for features from other tools or to change the interface to be more like other tools so they are familiar with using them. Â I had a nice little back and forth on Facebook on this one with a number of potential users wanting me to adapt the tool to their process and unless I did they were not interested. Â They just did not want to learn a new way or change the current way to adapt to the workflow of the application. Â You cannot fight this and if they are a big enough client adapt to their needs or pass on them as a client.
Time Starved
This was more common as to why they did not try it or want to try to learn a new tool. Â While this would save them time in the long run, the investment of time to review it and/or adopt it would take time they may not immediately have.
Every Day vs. As Needed
That is another key factor that will impact adoption – is it an essential tool that they use every day> Other than my Keyword Management System, most of what I have created are not every day tools.  They are these Frankenstein Tools that have a specific purpose and are not used all of the time.  This is one of the reasons I have struggled with price on these tools as they are not essential to day to day management for most users.   When they need it they need it and many will pay anything to fix or prevent problems but when they don’t have the problem they have no need.
Still learning as I go but I have realized these are the last tools I will make available.  It is just too hard and I don’t want to be a software developer.  I have gotten a lot of great feedback on all of them and some deserve to be made into products but others are just features of a large tool or part of my personal Frankenstein Toolbox.