They responded to the request with a “Maybe Later” status, which means they’ve not committed to implement this and there are other things that are a priority over it. It’s not completely off the table, but the following is the list of requests they’re currently giving priority to now:
These are all the items you have requested that we are currently working on.
Number of Votes also aren’t the only thing that matters in determining which Wishlist gets priority…If it were, there are still at least 71 wishlist requests with more votes than this one that haven’t been implemented yet anyway, so it would still be far down behind a lot of other requests.
Here's a list of things that can be taken into account in determining which requests get priority, besides number of votes or how long ago it was requested:
Note the following was written for the SD card “Fast Forward/Rewind” and scrubbing wishlist request:
The following are some common things companies like Wyze weigh against the popularity of their users’ requests/votes
(not all of them are applicable to this specific request, but I plan to refer to this later for others in general too, so I’m going to be thorough…):
TLDR; people can just scan the bolded points quickly
Technical Feasibility : Assess whether the requested feature or product is technically feasible with the current infrastructure and technology stack, which includes how Wyze’s app is currently structured vs needing to wait for a future revamp of their whole app first. It’s also possible that the older cameras don’t have the necessary resources (processor, RAM, etc) to even support doing this on the SD card. When I try to move forward or backward on some of the other cams, sometimes the camera stalls out. I think the older cams may not even be CAPABLE of supporting this. They could probably do it on some of the newer cams with more powerful resources though. We just don’t know for sure, but they probably do know.
Resource Allocation : Evaluate the resources required, including personnel, time, and budget, to implement the feature or product. Don’t misunderstand, I think this wishlist would be a GREAT ONE for the year of the camera, and I voted for it and support it. However, that would also mean taking away those same resources from other things that may be a higher priority in other ways for something that frankly wouldn’t necessarily bring back in what it costs to create it. It is more of a luxury feature than a necessary one. A Luxury feature I WANT and would love…but I can still do most of that manually or in other ways, so I haven’t LOST functionality without it.
Alignment with Company Goals I’m not saying this or any other one specifically does or doesn’t qualify, just saying this is a consideration they have to balance in general.
Market Demand : Do most or all other competitors offer it or are there lots who still don’t? Does it address a pain point for a significant portion of the user base?
User Impact : How would each of the thousands of requests impact the user experience and satisfaction? Not just of those most vocally requesting it, but the whole userbase.
Compatibility : Is it compatible with the rest of their hardware, software, services or general ecosystem? And not just functionally, but in general. For example, I’d think they were off their rocker and start thinking of ditching them if they started selling Goat Milk instead of tech products, no matter how many people requested it on the wishlist.
Regulatory and Legal Compliance : Something might be legal in some states but not in others, and it might not be worth it in some cases to try to comply with every state’s minutia and instead scrap the whole idea, or it might be worth it, and just require some extra resources to implement it. Point is that it’s a consideration for various requests.
Security and privacy : a lot could be said on this, but most of it is obvious
User Feedback : including things beyond the wishlist such as support tickets, surveys and user reviews, and even community engagement (also, while votes are one consideration in the wishlist, they have also mentioned how other things like analyzing thread activity, etc can also be a consideration)
Competition : in an AMA, the VP of product mentioned this was a big reason they were going to stop doing “Lifestyle Products” as he said: “Products like the Watch, which end up being fashion accessories, have been too crowded and complex for us to make significant traction in , so you’ll see less investment in these “Lifestyle” product lines as we continue to refine our focus back on these three core areas. ”
Scalability : Can it accommodate a growing userbase? Will it cause issues farther down the road?
Technical or Design Debt : This is actually one of Wyze’s biggest struggles right now. In this case, they already have a lot of limitations from the design debt of the foundational block of their app. This makes some things really hard to do, or to go back and change as far as it relates to UI updates. That could be an issue in this FF/RW wishlist since it would require UI changes. In other wishlists, they may also have to consider whether something would cause technical debt for future development or ecosystem expansion and compatibility concerns, including if they try to make any of their compatible with Matter standards.
Cost-Benefit Analysis : Will the expected benefits outweigh all the costs of implementation? This is a HUGE one that can’t be overstated.
Mass Appeal : Is the wishlist something that will benefit and be used by the majority of their users, or is it an edge case request or niche benefit that the majority would not use (this has been part of the rationale for why RTSP and API ecosystem integrations haven’t been implemented, since while a lot of us most active and most outspoken users want them, the majority of users would not benefit from them and they want to first devote resources and priorities toward things that almost EVERYONE can benefit from before they do things that will benefit smaller select percentages/groups).
Part of this could involve taking into consideration things like user base demographics, market research, surveys/feedback, user persona analysis, usability testing, data analytics, feedback aggregation, user impact assessments, user inclusivity, market differentiation, growth potential, long term impact, and many other things on this list)
User Opposition : The wishlist often doesn’t take into account whether implementing a feature might face opposition from a significant portion of the user base or raise concerns. I have seen tons of wishlist requests that I STRONGLY oppose, but there is no downvote option, and most of the other people who would oppose it aren’t in the thread because they are only looking for things they want and ignore the rest.
Integration : How easily it integrates into Wyze’s current ecosystem
Innovation : Is it an innovative and unique option that could differentiate Wyze from competitors
Longevity : Does it have long-term relevance or a short-term trend that’s not worth the investment
Sustainability : Including ongoing maintenance requirements and whether something aligns with the company’s sustainability goals
Phased implementation : Wyze actually does a lot of this. They will introduce something on a new product, and then depending on the response and use-metrics, they will then sometimes expand it to other models if it is well-received and worth the time and effort to do so.
Market research : To understand the size of the potential user base that could benefit or be reached by it to justify prioritizing the feature/product
User Education : would it require extensive user education for them to be able to use the feature, and are users willing to invest that time in learning it?
I’m sure there are a ton of others that Wyze takes into account that I either overlooked, forgot, etc. But, my main point is that it doesn’t really matter solely how long ago someone requested something, or even necessarily how many people voted for it. Those are certainly factors that matter, but there are dozens of variables that go into considering whether or not to implement a specific request. A wishlist may have a total green flag on 90% of the variables, but have one or 1 or 2 others with a red flag holding it up in a way in which another wishlist request with fewer votes actually gets priority ahead of it because of other factors. What I love about the way Wyze handles our requests is that they actually RESPOND to every request and label the expectation. In this case, Wyze didn’t PROMISE this request, but they gave us the courtesy of informing us they weren’t planning to implement it. They labeled it as “MAYBE Later.” They get around to telling us on each request if it is “Probably Not” or “Maybe Later” or “In Progress.” If they tell us Probably Not or Maybe Later, they have absolutely responded. It may not be the answer we hoped for, but at least they responded. That’s more than 99.99% of every other company out there. I acknowledge they won’t do the majority of the things I make requests for, but I am glad they give me the courtesy of responding. I’m not entitled to get everything I ask for. I bought their product either knowing it doesn’t have a feature, or when I get it and find out it doesn’t have that, They allow me to return it within 30 days for a refund so I can find something that DOES have what I want. That is 100% reasonable.
If I choose to keep a product, knowing it doesn’t support the thing I want, that’s on me. I can hope they consider changing things in the future, but I’m not entitled to it. I can return it when I find out it doesn’t have something and get something else instead.
Then I use this wishlist as "I’m already totally satisfied with my purchase, because you gave me the chance to get a refund and I decided it fit what I wanted already, but It would be SOOOO COOOL if you also did this." and then I get excited anytime they do add something, instead of being angry until they do so, which makes absolutely no sense to me. If I’m angry, I should’ve either not bought it or returned it when I found out it didn’t have it.
It would be nice to have recurring timelapse scheduling at some point, but with it being listed as “Maybe later” and having fewer than 200 votes and not very much activity, I don’t expect this to happen for a while if ever. However, the more people that contribute to the conversation like we are now, the better, and it will bring the topic to the top for others to see and be more likely to vote on it, and it will show there is still a demand for this feature and bring it to Wyze’s attention as they review the wishlist (the VP of product said in an AMA that they review the wishlist every week). So every little bit helps, but don’t get your hopes up too much on it being within the next 6-12 months since it hasn’t even been tagged as “researching” yet. Make any plans accordingly.