Thanks for data point. How is it interacting with the self-driving cars? I'm concerned that a lot of thought has gone into experience for the passenger of self driving car, but much less for the rest of general public. Feels like they missed an opportunity to improve driving experience for rest of us as well with some more signals or communication between vehicles.
In my experience as a pedestrian - they're extremely cautious, which I appreciate.
For most human drivers, I'll wave them through intersections if I'm on the far side and crossing will slow them down substantially -- partially out of sympathy for driving through slow crosswalks, partially out of self-preservation as drivers are often impatient and chomping at the bit to get through.
With the self-driving cars, they really creep up to the intersection so I never really consider waving them through (and I have no idea how they'd react). They're very good about not entering intersections when I'm approaching and they wait until I'm all the way through as well, so in my experience, they're very cautious. It's nice too since where I am in the sunset has random blocks with 4-way stops adjacent to 2-way stops, which is fairly dangerous for human drivers but the robotaxis handle those without issue.
Agree that relative to the cost in lives and global GDP leaders have drastically under invested in production and distribution of vaccines. Arguments about what ethical and incentive policies should be will continue forever. Certainly though we shouldn't be blocked at this point by availability of a few machines, shipping and inventory tracking, etc. Especially in the US we have really wasted 9-10 months to work on public health in general and vaccine delivery in particular. History will not be kind
Your next push is only as good as your last recovery. I'm surprised how often people focus on the work and neglect the recovery phase like nutrition, sleep, etc.
Go and talk with the people who wrote it. Often times there are a just a handful of people that wrote a lot of the core functionality, they often aren't the most social. Talk to them when you are in the planning phase of implementing something.
Lots of great advice here that I agree with. IMHO though I see a lot of engineers miss on the team and social aspects of coding. Just as important as your tech stack is your team. Have an idea for improving something? That's great, but remember to listen first and learn to love what is great about the way it is. For you it could be X% better for the original authors it is a miracle that they made it work at all and it is important enough to need a bigger team.
That, try to understand all the things that are not documented. Sure some projects may have written extensive documentation and all the options they considered and why the did what they did, but most of the decisions usually are not documented. Try to get into the mindset of those people and get into the conversation.
Please write a collaborative doc instead of an email if you have that much detail. Having an effective discussion over email is actively painful and worse yet no one can refer back to your detailed documentation later.
Good on you for communicating. Personally I've found that details are great, but being able to distill that core message down to a quick code really helps. Call it an elevator pitch, sound bite or whatever but it is really transformative. So much communication seems to be just passing along a historically linear repeat of facts rather than helping reader by distilling down.
Email is the worst but a close contender are Slack messages and threads .... Confluence is somewhat better but comments are not handled well with respect to the source document. Add in Smart sheet and the rest as kludges and I have 10 different things to check for a single project with dependencies.. it's nuts. I am not sure if anyone has really figured the information based workflow out yet. There needs to be some auto association and project based aggregation (maybe tags?) .. that and a personal workspace of things you need to do in each system.. right now everything is asynchronously propagated by slack or email.
I am interested in trying out Asana and Facebook Workplace to see if they have solved this in a more natural way.
Agree. Always seems odd that organizations say they want people to be productive and then pepper them with email, messages, and meetings. Some of the better teams I've been on developed unwritten rules about when/how to communicate and the importance of time for deep work, but all to often it was just a free for all of chat pings. I think when people talk about culture this is a large part of it - how do you keep people working effectively together without swamping communication bandwidth?
Some matrix math libraries like Eigen[1] support vectorization via SSE, AVX, NEON, etc. and also use cache friendly algorithms for larger matrices. Highly recommended when you don't need to go quite as low level as individual instructions.
If you need to work on large matrices, Eigen is highly recommended. If you need to do a stream of custom processing in small steps, Eigen is not a good fit. Eigen is a super complicated, template-heavy library that can compile very heavyweight tasks into very efficient code (eventually).
> Eigen is a super complicated, template-heavy library
I agree, but that feature allows to apply optimizations by specializing these templates.
Works for both micro-optimizations (in their pbroadcast4<__m256d> they do 4 loads, on many CPUs AVX2 can do better with a single load + shuffles) and replacing large parts of Eigen (I was able to improve performance of conjugate gradient solver by moving the sparse matrix into a SIMD-optimized structure).
I like the concept. Yet it feels like an echo chamber when the YC saas review company only reviews other YC based web analytics products after leading off with talk from YC parter about how everyone is doing it wrong... Do you think your audience won't notice the heavy YC bias?
Actually, I totally agree with you. This is something that we thought hard about, because our initial three guides are dominated by YC companies.
I think the main explanation is that YC companies, to a much greater extent than other companies, tend to focus on early-stage startups. As our guides are currently focused on early-stage startups, we naturally see more YC companies represented in the guides.
If anything, I'd argue that we're so aware of this that we need to consciously avoid overcorrecting in the other direction.
Have you thought about collecting reviews from "real" users of the products to supplement your analysis?
There's potentially a misaligned-incentives problem with review sites which themselves do the reviews. The latest episode of the FYI podcast[0] goes through this problem with the founder of Capiche[1] (looks like a competitor of yours) and the founder was explaining how firms like Gartner basically have two sets of customers: The software buys and the software sellers. The software sellers can actually pay Gartner to get in front of an analyst and sell them on their product.
I don't know to what extent this makes Gartner's recommendations less useful, but it seems like it would make it hard for smaller companies to get on the radar. I think the fundamental problem is that the analysts are not actual users of the software.
So I like Capiche's direction, but I dislike the fact that they're a "closed" invite-only website.
Thanks for mentioning Capiche! I think there's so much opportunity in this space so I'm stoked to see anyone else joining in.
At the very start, I wanted Capiche to be essentially Wirecutter for SaaS. We ended up going in a different direction, but I'm super impressed with Satchel's execution here, and as someone who spends a crazy amount of time on this stuff, I learned a bunch of new things reading through the site today.
I really don't want to hijack @fission's launch discussion, but thought I'd just reply to your comment on the invite-only thing: our site will be wide open soon-ish. Just taking our time building a community around high quality discussion (most of which has little to do with comparisons/reviews), but eventually will open it all up. Think of it like Stack Overflow's private beta...just a step in the process.
Hey Austin, I appreciate the thoughtfulness and the kind words.
I think even though we're working in different directions, we share a lot of the same values and see similar issues with the status quo. When (I hope not if) quarantine's over, let's grab a coffee :) — my email's in my profile
I think there are a couple of great points here, and I'll try to break things down and address each point independently.
1. re: "real" user reviews — right now, we do do this, just in a different way vs. what I think you're thinking of. For all of our guides so far, we've conducted a lot of interviews with founders who've used each product. However, we ultimately synthesize this data, pair it up with our own findings from our testing, and draw our own conclusions.
We think this is close to the optimal way of doing things. We found that sites which rely 100% on user reviews usually hit a ceiling in terms of usefulness, as the reviews are typically on the shallower side, which compounds b/c high-level reviews typically end up talking about the same things, so they're often redundant as well. By getting founder feedback, we're able to get a lot of datapoints to guide our findings and to surface less common issues, but by testing and ultimately writing these guides ourselves, we're able to both spend the time to elaborate on important aspects in depth (e.g. caveats, background info, etc.), while also being able to present info from a bigger picture perspective (e.g. this is how X, Y, and Z compare, etc.). The main downside is that it requires a lot of additional work.
2. re: Gartner + incentives — I believe that you identified the problem correctly, but misattributed the underlying cause. Gartner's incentives are misaligned b/c vendors who pay have an edge up on those who don't, for reasons you correctly identified. Importantly, this is not isolated to Gartner — in fact, the incentives are just as misaligned for a lot of the 100% UGC review sites. For those sites, if a vendor pays, they're allowed to cherrypick their own users to invite for an "organic review." If the vendor doesn't pay, then their rating will be relatively lower b/c it becomes much harder for them to get their best users to write a review on the site.
So in general, the problem isn't caused by whether you're a UGC review site or write guides yourself — it's caused by, well, whether or not you're doing something slimy to make money.
Edit: Oh, and I just saw that you mentioned Capiche at the end. I just want to say that none of this comment is directed at them — I sincerely think that they're passionate, motivated founders who deeply care about doing good for the startup community.
I think it's possible to have a system where lesser-known products can pay to get reviewed, and have the review still be unbiased and truthful. The probably is that it's impossible to know where that stops and "pay 1x to get reviewed, pay 2x for a good review" begins, and I think the vast majority of people would be immediately distrustful of any system where I can pay for my brand new, single-customer startup to get reviewed by a giant like Gartner.
I'm not sure I follow. Presumably, more mature SaaS products have more widely available reviews, documentation, tutorials, complaints, etc. to help companies make more informed decisions.
They also seem like they might have more proven business models, which is important when you're relying on it for a core function of your business. The last thing you want is some fresh startup that craters and forces you to scramble to find and implement a replacement when they fail to close their next funding round and need to shutter things.
Would you mind elaborating on what you don't follow on? I generally agree with everything you've said, so normally it'd be A-OK, but I think there's a question here somewhere (though I'm not exactly sure what) and I want to make sure I can address it.
It's more of a comment on your previous response than a question.
1. Older companies tend to have wider footprint of real world use in various contexts thereby having a wider "body of work" for objective analysis and review.
2. There is switching cost when you get the 'thank you from the incredible journey" email or blogpost. So it is important to have companies that are self-sufficient and aren't at the risk of being acquired and shutdown which new companies are much more prone to.
PS: It is acknowledged that new companies most likely have fresher takes on old problems but you should also cater for their negatives enumerated above.
There's definitely value and opportunity that can be found in using the newest tech from the freshest companies. You can often find great value from their pricing, better UI, improved results, etc.
So my comment was in no way meant to bash using a startup. It was meant more to point out that there's a double-edged sword here by focusing on startups as there are real risks and trade-offs.
I agree this would be a problem. If I am using a review to pick a tool I want to know they’ve tried the old tool from Oracle and IBM and Microsoft and they are treating it as seriously as I would as the person that has to pay the bill.
I also agree that this is a problem. This is why we're evaluating the old-school solutions for each problem. For payroll, this is ADP + PayChex; for knowledge bases this is Confluence; for payment processors we're even dealing with Authorize.net, even though I'd think most startups would eliminate that choice based on repressed memories alone.
I believe we've also done a good job of this in our current guides: we discuss LegalZoom and lawyers in our incorporation service guide (even though bonafide startup incorporation services themselves are relatively novel), and for our store of money guide we even went so far as to stick our money into Fidelity (the definition of old school) to get a cash management comparable.
Our event-based analytics guide doesn't have any old school evaluation, but that's because event-based analytics tools, in the grand scheme of things, are really quite a recent development.
This really comes across in the choice of Brex for storing cash. I don't think most VCs would be comfortable with portfolio companies storing their millions with Brex (unless they are investors in Brex). Startup CFOs are not chasing yield with investor's money and really want the safest, most convenient option, that builds a relationship for the future if the company is successful.
Money Market funds are a good option to store cash that one needs for the immediate term, and there is a wide variety of them. However, one should evaluate each fund and their holdings to understand the risk & liquidity profiles.
Full Disclosure: I'm the founder of InterPrime (yc w19). We provide treasury management services and bring the treasury tools that big companies have been using for decades to Startups, SMBs, Non-profits & Investment Funds. Happy to chat and help anyone with questions on these topics.
This is actually a really interesting comment, because it reminds me of a meta-observation that I've made over the past few weeks.
First off though, I want to clarify that the money market fund is typically not operated by the org. The GMMF choices for SVB are managed by BlackRock, Morgan Stanley, etc., for Brex it is BNY Mellon, etc. You really only get self-operated funds for larger financial institutions, e.g. Wells Fargo or Fidelity. Therefore, many of these products act as a software layer over some existing bank/fund/etc. I believe we explain this distinction in the article. There are some caveats, but this is the general gist.
But onto the meta-observation: given the current economic climate w/ depressed treasury rates, we've recently received a lot of questions about higher-yield options, specifically re: CDs which are currently hovering around 1.5%. These are from well-known, well-respected startups who presumably don't need the cash and don't need to deal with the high overhead and illiquidity of CDs. I think that this really demonstrates the survival instincts of later-stage founders being carried forward from their early days, and the fact that startups are functionally live optimization machines, not just at a product-level, but as an entire organization. It seems to us that the best startups eke out every advantage they can — with all respect to the nature of the power law, these small differences, in aggregate, might make or break the entire company.
As convenient as it would be to have a single scapegoat to hang the problems on like the dreaded "tech industry" my experience is that housing shortages in Santa Cruz is a complex multi factor problem. Some example contributing factors:
- UC Santa Cruz has increased enrollment to 19,500 students with only just around half of them living on campus. Living on campus is relatively expensive at $1940 for room & board to share a room [1,2]
- Considering Santa Cruz itself has just around 65,000 residents the half of students living off campus make up 15% of population
- Certainly people commute over to tech for higher pay, but according to HUD that number has climbed just 4% from 26-30% between 2005 to 2015 [3]
- Santa Cruz itself greatly limits development with annual permits averaging around 250 for the past 10 years and almost all single family homes and townhomes rather than higher density [4]
- California's entire real estate market has been warped by Prop 13 which fixes real estate taxes to the time property was purchased with limited increases [5]. This incentivizes companies and people to stay on a property longer than other real estate markets as they have lower taxes. It also dissuades towns from building housing as long term the costs such as schools, services, etc. go up with market, but not tax revenues.
The availability and cost of housing in California and Santa Cruz is a real problem for many people. I've seen a lot of finger pointing with people's favorite scapegoats. I'd like to see the same energy go into the difficult work of city planning for construction, transportation, schools, etc.
