I love the MVP approach to applications, and it is how I build all my tools – build just the essentials necessary to get the job done. What I have found out is that while that works great for personal consumption it has different challenges and expectations when you apply it to commercialized tools.
If you are not familiar, with 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 thoroughly bake it. This process forces you to identify what are the minimum features and functions necessary for others to want to adopt it. I do think this is an excellent approach to application and product development but it 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 through 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 an 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 unexpected.
Different Approach to Similar Problems
I often have a different approach to SEO challenges than many other consultants in the search industry. I have learned over the years the root cause of poor performance based on a systems failure diagnosis. To accommodate my workflow, I have had to build a few custom tools to serve these purposes. A few months ago during a session on Diagnosing SEO Performance Issues, I shared my screen and used some of the tools I created. After the session, a number of attendees asked if they could try them or license them so I took the time to make them available. This is where the fun began.
A big thing for developers to overcome is their opinion of the importance of a feature to the potential customer. The problem or need that triggered the need for the tool creation initially for me may not be of the same importance as 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 type of tool? There is no need for it because it is a new problem. There is not a big enough need for a tool Can they use a workaround with another tool?
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 the one that I got the most pushback 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 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 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 the final post-beta pricing before investing time in testing the tool. I can understand that if it becomes too 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 want to price consistent with other non-related tools. For example, in 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 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.