flâneur

Peyton Seigo

0 followers · 732 views

on the atlas — 15

highlights — 70

  • If you're building something for which you can't easily get a small set of users to observe — e.g. enterprise software — and in a domain where you have no connections, you'll have to rely on cold calls and introductions. But should you even be working on such an idea?
    Do Things that Don't Scale
  • Another consulting-like technique for recruiting initially lukewarm users is to use your software yourselves on their behalf.
    Do Things that Don't Scale
  • The most common unscalable thing founders have to do at the start is to recruit users manually. Nearly all startups have to. You can't wait for users to come to you. You have to go out and get them.
    Do Things that Don't Scale
  • The need to do something unscalably laborious to get started is so nearly universal that it might be a good idea to stop thinking of startup ideas as scalars. Instead we should try thinking of them as pairs of what you're going to build, plus the unscalable thing(s) you're going to do initially to get the company going.
    Do Things that Don't Scale
  • Google grew big on the back of Yahoo, but that wasn't a partnership. Yahoo was their customer.
    Do Things that Don't Scale
  • Some startups could be entirely manual at first. If you can find someone with a problem that needs solving and you can solve it manually, go ahead and do that for as long as you can, and then gradually automate the bottlenecks.
    Do Things that Don't Scale
  • There's a more extreme variant where you don't just use your software, but are your software. When you only have a small number of users, you can sometimes get away with doing by hand things that you plan to automate later. This lets you launch faster, and when you do finally automate yourself out of the loop, you'll know exactly what to build because you'll have muscle memory from doing it yourself.
    Do Things that Don't Scale
  • When we approached merchants asking if they wanted to use our software to make online stores, some said no, but they'd let us make one for them. Since we would do anything to get users, we did. We felt pretty lame at the time. Instead of organizing big strategic e-commerce partnerships, we were trying to sell luggage and pens and men's shirts. But in retrospect it was exactly the right thing to do, because it taught us how it would feel to merchants to use our software. Sometimes the feedback loop was near instantaneous: in the middle of building some merchant's site I'd find I needed a featur…
    Do Things that Don't Scale
  • Consulting is the canonical example of work that doesn't scale. But (like other ways of bestowing one's favors liberally) it's safe to do it so long as you're not being paid to. That's where companies cross the line. So long as you're a product company that's merely being extra attentive to a customer, they're very grateful even if you don't solve all their problems. But when they start paying you specifically for that attentiveness — when they start paying you by the hour — they expect you to do everything.
    Do Things that Don't Scale
  • Sometimes we advise founders of B2B startups to take over-engagement to an extreme, and to pick a single user and act as if they were consultants building something just for that one user. The initial user serves as the form for your mold; keep tweaking till you fit their needs perfectly, and you'll usually find you've made something other users want too.
    Do Things that Don't Scale
  • Like paying excessive attention to early customers, fabricating things yourself turns out to be valuable for hardware startups. You can tweak the design faster when you're the factory, and you learn things you'd never have known otherwise.
    Do Things that Don't Scale
  • Hardware startups face an obstacle that software startups don't. The minimum order for a factory production run is usually several hundred thousand dollars. Which can put you in a catch-22: without a product you can't generate the growth you need to raise the money to manufacture your product.
    Do Things that Don't Scale
  • Among companies, the best early adopters are usually other startups. They're more open to new things both by nature and because, having just been started, they haven't made all their choices yet. Plus when they succeed they grow fast, and you with them.
    Do Things that Don't Scale
  • If you have to choose between the subset that will sign up quickest and those that will pay the most, it's usually best to pick the former, because those are probably the early adopters. They'll have a better influence on your product, and they won't make you expend as much effort on sales. And though they have less money, you don't need that much to maintain your target growth rate early on.
    Do Things that Don't Scale
  • The feedback you get from engaging directly with your earliest users will be the best you ever get. When you're so big you have to resort to focus groups
    Do Things that Don't Scale
  • Your user model almost couldn't be perfectly accurate, because users' needs often change in response to what you build for them. Build them a microcomputer, and suddenly they need to run spreadsheets on it, because the arrival of your new microcomputer causes someone to invent the spreadsheet.
    Do Things that Don't Scale
  • your initial model of users is always inaccurate, even if you're one of them.
    Do Things that Don't Scale
  • Even if you start the way most successful startups have, by building something you yourself need, the first thing you build is never quite right. And except in domains with big penalties for making mistakes, it's often better not to aim for perfection initially. In software, especially, it usually works best to get something in front of users as soon as it has a quantum of utility, and then see what they do with it.
    Do Things that Don't Scale
  • What founders have a hard time grasping (and Steve himself might have had a hard time grasping) is what insanely great morphs into as you roll the time slider back to the first couple months of a startup's life. It's not the product that should be insanely great, but the experience of being your user. The product is just one component of that. For a big company it's necessarily the dominant one. But you can and should give users an insanely great experience with an early, incomplete, buggy product, if you make up the difference with attentiveness.
    Do Things that Don't Scale
  • Once you realize that existing conventions are not the upper bound on user experience, it's interesting in a very pleasant way to think about how far you could go to delight your users.
    Do Things that Don't Scale
  • Garry Tan pointed out an interesting trap founders fall into in the beginning. They want so much to seem big that they imitate even the flaws of big companies, like indifference to individual users. This seems to them more "professional." Actually it's better to embrace the fact that you're small and use whatever advantages that brings.
    Do Things that Don't Scale
  • But perhaps the biggest thing preventing founders from realizing how attentive they could be to their users is that they've never experienced such attention themselves. Their standards for customer service have been set by the companies they've been customers of, which are mostly big ones. Tim Cook doesn't send you a hand-written note after you buy a laptop. He can't. But you can. That's one advantage of being small: you can provide a level of service no big company can.
    Do Things that Don't Scale
  • Maybe if they go out of their way to make existing users super happy, they'll one day have too many to do so much for. That would be a great problem to have.
    Do Things that Don't Scale
  • part of the reason engineering is traditionally averse to handholding is that its traditions date from a time when engineers were less powerful — when they were only in charge of their narrow domain of building things, rather than running the whole show.
    Do Things that Don't Scale
  • You should take extraordinary measures not just to acquire users, but also to make them happy.
    Do Things that Don't Scale
  • How do you find users to recruit manually? If you build something to solve your own problems, then you only have to find your peers, which is usually straightforward. Otherwise you'll have to make a more deliberate effort to locate the most promising vein of users. The usual way to do that is to get some initial set of users by doing a comparatively untargeted launch, and then to observe which kind seem most enthusiastic, and seek out more like them. For example, Ben Silbermann noticed that a lot of the earliest Pinterest users were interested in design, so he went to a conference of design bl…
    Do Things that Don't Scale
  • The question to ask about an early stage startup is not "is this company taking over the world?" but "how big could this company get if the founders did the right things?" And the right things often seem both laborious and inconsequential at the time.
    Do Things that Don't Scale
  • It's harmless if reporters and know-it-alls dismiss your startup. They always get things wrong. It's even ok if investors dismiss your startup; they'll change their minds when they see growth. The big danger is that you'll dismiss your startup yourself.
    Do Things that Don't Scale
  • In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone. Of course, it is preferred to make things better for multiple constituencies at once.
    HTML Design Principles
  • This is a metaphor indicating that you need not argue about every little feature just because you know enough to do so. Some people have commented that the amount of noise generated by a change is inversely proportional to the complexity of the change.
    Why Should I Care What Color the Bikeshed Is?
  • just because you are capable of building a bikeshed does not mean you should stop others from building one just because you do not like the color they plan to paint it
    Why Should I Care What Color the Bikeshed Is?
  • I wish we could let people build a bike shed every so often, and I don't really care what colour they paint it.
    Why Should I Care What Color the Bikeshed Is?
  • A team spent _years_ on this and they justified the project institutionally and publicly not by saying "let's build a proof of concept" but by saying "let's replace CVS". And, sure enough, if you suggest to them a stop-and-think phase at this late date you get back, basically: "Um...no...not gonna happen." I won't label that one of their mistakes because I don't think the root cause is something they could have easily avoided.
    [arch-users] diagnosing svn
  • Well, I think Berkeley DB is a lousy choice for this application. It creates administrative headaches, and it's optimized for simple associations, not hierarchical filessytems. It doesn't natively provide any sort of delta-compression -- you'll have to layer that. Ultimately _all_ that it buys you is transactions and locks -- every other aspect is a force-fit. And what resulted? Sure enough: years of fighting against excessive space consumption, disk-filling log files, and poor performance, characterized by substantial rewrites of core functionality and API changes.
    [arch-users] diagnosing svn
  • The transactional filesystem idea is, indeed, conceptually simple and elegant. The reality of implementing it, however, is a swamp of external considerations and inconvenient realities. Supposing you want to achieve high transaction rates and size-scalability. You have a _lot_ to consider: locking (contention over the root of the tree is especially fun), deadlocks, logging, crash recovery, physical layout of data, I/O bottlenecks, network protocols, etc. etc.
    [arch-users] diagnosing svn
  • F) The API Fallacy When you lack confidence about your intended way to implement something, a common pattern is to decide to hide the implementation under an API. That way you can always change the implementation later, right? The problems are: (1) unless you have at least one fully worked design for how to implement your API, you shouldn't have any confidence that good implementations can exist; (2) unless you have at least two fully worked designs for how to implement your API, and they make usefully contrary trade-offs, you should really start to wonder whether doing extra work to make an a…
    [arch-users] diagnosing svn
  • D) Narrow design focus combined with grand technology ambitions The original contributors included people who worked on CVS, people who used CVS, and people working on products that incorporate CVS. In some sense, the itch they must have had in common was "Get this CVS monkey off my back; I'm sick of it." At the same time, they (justifiably) had their eyes on a real treasure -- that transactional filesystem database. In that context, it'd be hard to get behind the idea of just incrementally fixing CVS. It'd be hard to invent meta-CVS, for example. As the project has progressed, over the years,…
    [arch-users] diagnosing svn
  • mistake: insufficient skepticism about their own design sketches, early on.
    [arch-users] diagnosing svn
  • Application of patterns like property lists in a design bull session all too easily gives rise to the feeling that "all the problems we're thinking about have natural solutions in this design" even though all you're really saying is "the problems we need to solve can be expressed in terms of associative lookup".
    [arch-users] diagnosing svn
  • the problem with some design patterns like attaching property lists to everything under the sun: they don't really solve design problems but they give you an operational language in which to _restate_ design problems. It's sometimes very hard to recognize the difference between a restatement of a design problem in operational terms and its actual solution.
    [arch-users] diagnosing svn
  • there's so little effective mentoring in the industry from old-salts who are good at making a religion of the K.I.S.S. principle and making fun of the wealth of bloated, crappy, yet slow-to-fail stall-ware projects that dominate so much of the landscape
    [arch-users] diagnosing svn
  • a pit of overconfidence which is hard to recognize from the inside until you've experienced a few disasters
    [arch-users] diagnosing svn
  • bad circumstance: crappy socio-economic circumstances for smart, ambitious programmers in the free software industry and community -- way too much weight given to what supposedly successful projects "smell like" and too much resulting pressure on hackers to project an image resembling that false idol.
    [arch-users] diagnosing svn
  • Since we were only “two months” from shipping, making changes to the engine for the better was regularly passed over for band-aiding existing but sub-optimal solutions, which led to many months of suffering, so much that it affected my approach to coding (for the better) ever since
    Tough times on the road to Starcraft - Code Of Honor
  • Incidentally, these sorts of crazy hours weren’t mandated — it was just the kind of stuff we did because we wanted to make great games. In retrospect it was foolish — we could have done better work with more reasonable efforts.
    Tough times on the road to Starcraft - Code Of Honor
  • Working these long hours made people groggy, and that’s bad when trying to accomplish knowledge-based tasks requiring an excess of creativity, so there should have been no surprises about the number of mistakes, misfeatures and outright bugs.
    Tough times on the road to Starcraft - Code Of Honor
  • But the programming team continually worked towards shipping in only two months for the next fourteen months!
    Tough times on the road to Starcraft - Code Of Honor
  • With its troubled early history, after the reboot the development team was pressured to finish up, and so schedules were bandied about that showed the game could be launched in two months.
    Tough times on the road to Starcraft - Code Of Honor
  • The Warcraft engine had taken months of programming effort to get right, and while it needed rework for new gameplay features, a fresh programming team was now going to spend a great deal of time relearning lessons about how and why the engine was architected the way it was in the first place.
    Tough times on the road to Starcraft - Code Of Honor
  • There are good reasons code needs to be rewritten, but excising old code comes with risks as well.
    Tough times on the road to Starcraft - Code Of Honor