The conversation

Lessons learnedExperience excerpt · English

It takes a serious block of time to evaluate any product or service, maybe a few days

… It takes a serious block of time to evaluate any product or service, maybe a few days. If I put a few days into an open source product and I like it I can just use it. If it is a paid product I'm going to have to go to my management, it might be easy or it might be hard, but I have to discount the gains from "I found a product I like" by the probability that "we won't buy it anyway" so that makes me all the more hesitant to complete a trial.

Original discussionA fourteen-day free trial ain’t gonna cut it224 source comments · at import
6

Community replies 0

No community replies yet. Add your perspective.

Replies from the source 6

Direct replies available in this import. Original-language excerpts.

GA

My team is responsible for the research, evaluation, approval, integration, and on-going support for each and every single platform that is within our stack. We have a lengthy standardized process for evaluation/scoring/approval and one of our mandates is a minimum of 30 days, no payment, and no Sharewaresque limitation in functionality. If we cannot get 30 days, it's a simple 'no,' and we move on to the next. Even at 30 days, it's extremely stressful on the team to get the system up and running, ingest our test case data, and run our tests. This is after going through this process >100 times. There's simply no way to get everything that needs to be done with an evaluation of even basic coverage in less than 30. Full stop. Lack of adequate understanding of the potential challenges an org is going to face during implementation and use is, IMO, the single biggest reason implementations run…

Full original
DY

In my experience, I've only looked at new software when the text on the box says that it'll solve an issue we currently have, dramatically improve existing workflows, or specifically asked by someone else. If you're concerned about time , then maybe you (or your company) are doing it wrong. Depending on the size of your company, there should be a team of people assigned time to specifically evaluate theNewShiny whatever. If the product does not do what is advertised on the tin, then drop it and move on. If it does work as advertised, the team then evaluates next steps in how to utilize it. In this way, that research is already "budgeted" into employee's time.

Full original
TO

Sounds like you need a first filter, and then only do your evaluation process on a given product if it solves a major pain point and even in that case, just evaluate the best/most common product in that category and only if it clearly doesn't work test another product. You are not going to win as a startup by using Teams, even if it is cheaper than Slack+Zoom, you are going to win big or not at all and focusing on things that don't matter for the core success just means less time to make something people want.

Full original
GR

And the time to evaluate for something you're releasing (vs staying in your control on SaaS) is significantly higher. Things that lock you in, especially between your released software and hosted services -- like authentication, installers/auto-update, and licensing (keygen) -- are even higher than that. It's just really hard to "undo" these things, both technically and because of the optics (user experience). Requiring your users to re-license their software is friction -- it burns user trust and costs a lot of time in support. 14 days is just too short to evaluate if the product will even meet your needs, let alone evaluate how much lock-in there is and what the path away could look like.

Full original
DA

Implementers failing to prioritize doing some legwork during the free trial period also costs time for the sales organization of the selling party. From the sales side, if we see the prospect the finding a solution is a low enough priority that their engineers can’t spend time in two weeks to simply look at a solution, then they might not be an ideal fit for the product (they don’t enough business pain, don’t have a champion, and/or don’t have an economic buyer to prioritize the purchase of a solution). This is of course highly dependent on the nature of the software and the ideal customer profile of that solution, but the fact that there’s two sides of this coin is something to keep in mind.

Full original
DR

From the ops side my situation's similar. The more so as the team is often small (one-person ops teams are probably the norm, at least by number of establishments), and workload is often already overwhelming. New technology and/or products always come with unanticipated consequences and downsides. Expecting to make a decision on a major, or even minor tool isn't something that can be rushed. One model I'd noted as innovative at the time was for a SAAS company to offer a free tier of service, in the case in mind, with limited data retention of a monitoring tool. That struck me as an exceedingly good way to balance the power of the tool (all other features were otherwise available), whilst also providing a clear and reasonable upgrade path to a paid subscription. When that company IPO'd and revealed its CoS (cost of sales), I was surprised to see how high it remained (on the order of 40--5…

Full original
Continue on Hacker News

Respect different perspectives. Share concrete experiences.

Sign in to post, reply, repost, and quote.