I would respectfully disagree with this, my long-time friend. I am totally okay when we don’t see eye to eye, but I want to share my perspective on this so I can refer other people to this in the future because I see lots of people who feel the same way that you do, and I’d like to share how I see it.
There are THOUSANDS of wishlist requests, and often multiple more per day being created.
As Wyze has said in the past, implementing a wishlist request has to be a balance of popular demand as well as MANY other factors. Keep in mind that I am in SUPPORT of this wishlist and want it to be implemented, so don’t think I am arguing against it. I am just trying to explain why it can be reasonable for a wishlist to take a long time or to not ever be implemented in some cases even if it is “popular”.
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. 
Again, I voted for and support this wishlist, and definitely am excited at the news that they appear to be working on something for this here. I am just saying, I’m not mad it took so long because I knew it didn’t exist when I got my product, and I chose to keep it still, and I realize there are a TON of variables for them to consider when deciding which wishlist items take priority. But I get an update about every wishlist item they complete, and they are always adding new stuff for us. Here is a list of several Wishlist items they’ve added due to user input:
And that doesn’t count all the things they added that were requested outside the wishlist, nor all the rules and actions and other things that are aggregated elsewhere. They DO add things for us, but again, there are THOUSANDS of requests and they have to weigh all the other factors to determine what gets priority.