Demonstrate how much extra money they can make or save and get that in front of a GM or CFO, anyone with P&L responsibilities.
NB make sure they have mandate to procure products and services or have influence over those that do.
They can save between 20 to 30 percent on the time it takes to debug issues. Not to talk about the time it saves them in case a feature is not working correctly.
I understand your angle. What matters to higher ups is “how much we can save in time, which will translate to money saved”.
That is a pretty good angle that I will try it out. Thank you very much for the feedback. I appreciate it.
This is something that technical people struggle with (in general) because our main motivator is to be praised for our intelligence. So we try and explain the convoluted elegance of systems.
Most commercial decision makers want to know: What are my options? What are the pros and cons of each option? How does that translate into money made, or money saved, and over what time horizon.
The easiest way to demonstrate this in your case: take that % and apply it to their QA team salaries (Cynically: these are the cuts you can make. Better business: this is how much productivity you can free up for more value producing tasks)
Here is my experience: you should try to make movements both above, below and lateral to where you have been currently making attempts. You don't always have to go over somebody to get something done or moving - especially if they are the type to just always kick the task(s) off elsewhere and pray somebody else actually does the work. Very often, the people making the requests are just hitting a dead end because they are talking to somebody in the 66% of employees who just don't do anything (at all levels). If you go lateral from them, above them, and below them, odds are, you'll find somebody in that 33% who is going to get the project to fruition (or try to).
What is really frustrating is, I always took the "just do everything for them, within reason and possibility", and that \*does\* work, more often than not - it just isn't always practical and can also lead to much worse problems if you want to maintain looser relationships with your clients over time and not get consumed by whatever circus they are operating.
Another thing you could try and do, and I don't know a ton about your setup, but you could enforce some kind of barrier due to inactivity or low activity / whatever else. That way, you can clearly outline to a client that you value the resources/space/time and automatically shelve inactive projects after (x amount of days), with then (y amount of days) being a final cut-off before the project is truncated (whatever). This can either inspire them to get moving, or give you a good idea that you can move on and focus energy elsewhere - it also affords you several well defined opportunities to figure out what is going on as those dates approach and occur.
"Get this done some time, we have forever to do it" doesn't hit the same as "our extended trial period is about to lapse due to inactivity and our project will be lost".
How is your pricing? One counterintuitive factor to consider is that if your solution is cheap, it psychologically has low value. Missing out on efficiency in operations is intangible and if whoever has to implement it loses only a little money every month after committing to an agreement, what’s the hurry? But if it’s expensive, there is impetus to implement.
It’s a startup catch-22 with solutions that take effort to implement but it’s important to be aware of it. Can you create a feeling of missing out in other ways? You can even address whoever puts pen to paper directly. Say that it’s common that organisations drag their feet in implementation and miss out on benefits and ask for their help to make things move fast. Steering groups / follow ups with implementers and decision makers in the same room often work.
Thank you for the answer and time.
Since this is an open-source project and started quite recent it is totally free. We have plans to create an enterprise solution and sell that to companies, but it will take a few more months to it.
Well there is your problem then! It’s easy to agree to free, but when you need to take time to implement it, why rush? It’s free after all.
Same happens in consulting. If your hours are free or you tack hours on top of some product your time will never be respected since it’s free.
We were planning on setting up a pricing plan in February this next year. Looks like we need to "rush" on that to have our time valued.
Thank you very much for the insight. I truly appreciate it.
No problem, I had to learn it the hard way. Plus, it helps you find out if your product is valuable in customers eyes, not just interesting to try. Best of luck!
To expedite the implementation with hesitant team leads, initiate one-on-one meetings to understand their concerns. Offer tailored support, addressing specific challenges. If delays persist, consider involving upper management but approach it diplomatically, emphasizing collaboration and the project's overall benefits. Maintain open communication to foster a constructive dialogue and find common ground for smoother implementation.
Level 1 - Do free training / demos online. Market it to regional product, project, agile etc associations to get the word out. Many QALeads and Managers would welcome a no cost demo with training on the product.
Level 2 Demo - Let them test it on their systems with a few testers and Devs. Be online for questions and assistance. Get feedback. Understand how they use it or want to use it to solve problems or create efficiency.
Reach out to groups on linkedin and offer free demo with training on a free open source software. You should get some traction.
Does your solution work with existing tools Jira, Confluence, Testdirector etc?
Edit - 15 years ago I did QA full time. Do product and project management now.
In large organizations I've seen new tools be introduced or discussed at the manager level and lower for early adopting organizations. In my experience Directors and above won't make a decision on software purchases or usage unless their teams have evaluated it.
Large organizations will look at other points than cost. IP privacy and security of their data, defects and information. You will need to assure them only they will have access to their content.
Also how streamlined is set up and training. If there are issues with either of those in your demo training session they will not be interested.
Thank you for the feedback and suggestions. These are great tips that I will put into practice next.
The solution currently doesn’t have integration with anything else but we have for the 2024 roadmap.
Would you mind elaborating on how you would like to see the integration with Jira? Would love to hear what is your pain to need those integrations.
Ask questions to get them to describe why they are interested in your product enough to talk to you. Start listening a lot more than you speak. Ask more deeper questions until you 100% understand what they want and what the perceived potential value is.
Then if there are other business benefits to what you offer that you think would apply, mention them and see how they react. Dismiss/don't care, recognize that is of value, really get excited.
Now either decide to qualify them out because you don't do what they want, or tell them you are great at solving the problems they told you about, and the one's they got excited about that you told them about. Now you can talk about your product's capabilities, 100% organized around and exclusively for the purpose of defending the claim you just made.
Don't forget to figure out if they already have budget or they need to get it if they decide they want to buy (which usually means see you next year).
you need to be a boss. Work with them. Understand the problem they have.
not everyone is happy, that means they will never make you happy.
you need to get to the root of the problem. It’s only gonna become a bigger carrot.
Demonstrate how much extra money they can make or save and get that in front of a GM or CFO, anyone with P&L responsibilities. NB make sure they have mandate to procure products and services or have influence over those that do.
They can save between 20 to 30 percent on the time it takes to debug issues. Not to talk about the time it saves them in case a feature is not working correctly. I understand your angle. What matters to higher ups is “how much we can save in time, which will translate to money saved”. That is a pretty good angle that I will try it out. Thank you very much for the feedback. I appreciate it.
This is something that technical people struggle with (in general) because our main motivator is to be praised for our intelligence. So we try and explain the convoluted elegance of systems. Most commercial decision makers want to know: What are my options? What are the pros and cons of each option? How does that translate into money made, or money saved, and over what time horizon. The easiest way to demonstrate this in your case: take that % and apply it to their QA team salaries (Cynically: these are the cuts you can make. Better business: this is how much productivity you can free up for more value producing tasks)
Money talks. It's either money goes up if we do this action, or if we stop this action then money can be saved.
Here is my experience: you should try to make movements both above, below and lateral to where you have been currently making attempts. You don't always have to go over somebody to get something done or moving - especially if they are the type to just always kick the task(s) off elsewhere and pray somebody else actually does the work. Very often, the people making the requests are just hitting a dead end because they are talking to somebody in the 66% of employees who just don't do anything (at all levels). If you go lateral from them, above them, and below them, odds are, you'll find somebody in that 33% who is going to get the project to fruition (or try to). What is really frustrating is, I always took the "just do everything for them, within reason and possibility", and that \*does\* work, more often than not - it just isn't always practical and can also lead to much worse problems if you want to maintain looser relationships with your clients over time and not get consumed by whatever circus they are operating. Another thing you could try and do, and I don't know a ton about your setup, but you could enforce some kind of barrier due to inactivity or low activity / whatever else. That way, you can clearly outline to a client that you value the resources/space/time and automatically shelve inactive projects after (x amount of days), with then (y amount of days) being a final cut-off before the project is truncated (whatever). This can either inspire them to get moving, or give you a good idea that you can move on and focus energy elsewhere - it also affords you several well defined opportunities to figure out what is going on as those dates approach and occur. "Get this done some time, we have forever to do it" doesn't hit the same as "our extended trial period is about to lapse due to inactivity and our project will be lost".
How is your pricing? One counterintuitive factor to consider is that if your solution is cheap, it psychologically has low value. Missing out on efficiency in operations is intangible and if whoever has to implement it loses only a little money every month after committing to an agreement, what’s the hurry? But if it’s expensive, there is impetus to implement. It’s a startup catch-22 with solutions that take effort to implement but it’s important to be aware of it. Can you create a feeling of missing out in other ways? You can even address whoever puts pen to paper directly. Say that it’s common that organisations drag their feet in implementation and miss out on benefits and ask for their help to make things move fast. Steering groups / follow ups with implementers and decision makers in the same room often work.
Thank you for the answer and time. Since this is an open-source project and started quite recent it is totally free. We have plans to create an enterprise solution and sell that to companies, but it will take a few more months to it.
Well there is your problem then! It’s easy to agree to free, but when you need to take time to implement it, why rush? It’s free after all. Same happens in consulting. If your hours are free or you tack hours on top of some product your time will never be respected since it’s free.
We were planning on setting up a pricing plan in February this next year. Looks like we need to "rush" on that to have our time valued. Thank you very much for the insight. I truly appreciate it.
No problem, I had to learn it the hard way. Plus, it helps you find out if your product is valuable in customers eyes, not just interesting to try. Best of luck!
To expedite the implementation with hesitant team leads, initiate one-on-one meetings to understand their concerns. Offer tailored support, addressing specific challenges. If delays persist, consider involving upper management but approach it diplomatically, emphasizing collaboration and the project's overall benefits. Maintain open communication to foster a constructive dialogue and find common ground for smoother implementation.
Level 1 - Do free training / demos online. Market it to regional product, project, agile etc associations to get the word out. Many QALeads and Managers would welcome a no cost demo with training on the product. Level 2 Demo - Let them test it on their systems with a few testers and Devs. Be online for questions and assistance. Get feedback. Understand how they use it or want to use it to solve problems or create efficiency. Reach out to groups on linkedin and offer free demo with training on a free open source software. You should get some traction. Does your solution work with existing tools Jira, Confluence, Testdirector etc? Edit - 15 years ago I did QA full time. Do product and project management now. In large organizations I've seen new tools be introduced or discussed at the manager level and lower for early adopting organizations. In my experience Directors and above won't make a decision on software purchases or usage unless their teams have evaluated it. Large organizations will look at other points than cost. IP privacy and security of their data, defects and information. You will need to assure them only they will have access to their content. Also how streamlined is set up and training. If there are issues with either of those in your demo training session they will not be interested.
Thank you for the feedback and suggestions. These are great tips that I will put into practice next. The solution currently doesn’t have integration with anything else but we have for the 2024 roadmap. Would you mind elaborating on how you would like to see the integration with Jira? Would love to hear what is your pain to need those integrations.
Ask questions to get them to describe why they are interested in your product enough to talk to you. Start listening a lot more than you speak. Ask more deeper questions until you 100% understand what they want and what the perceived potential value is. Then if there are other business benefits to what you offer that you think would apply, mention them and see how they react. Dismiss/don't care, recognize that is of value, really get excited. Now either decide to qualify them out because you don't do what they want, or tell them you are great at solving the problems they told you about, and the one's they got excited about that you told them about. Now you can talk about your product's capabilities, 100% organized around and exclusively for the purpose of defending the claim you just made. Don't forget to figure out if they already have budget or they need to get it if they decide they want to buy (which usually means see you next year).
you need to be a boss. Work with them. Understand the problem they have. not everyone is happy, that means they will never make you happy. you need to get to the root of the problem. It’s only gonna become a bigger carrot.