TFTC: A Bitcoin Podcast - #465: Five Pillars of Product Management with Will Cole

Episode Date: December 4, 2023

Marty sits down with Will Cole to discuss his new writing on the five invariant elements of product management and how to build an effective strategy for your company. Will on Twitter: https://twitter.com/willcole 0:00 - Intro 6:17 - Marty is sleepy 11:07 - Stories behind Will’s writing 19:10 - Invariants and levels of abstraction 30:25 - Why a product manager exists 33:57 - Think, then do 36:30 - Running through the invariants and strategy doc 42:41 - Timeline 46:55 - Minimizing meetings with good writing 48:53 - Iterating vs incrementing 56:44 - Who has better and worse product management? 1:00:24 - Managing growth 1:08:48 - Cmon Marty write the doc 1:12:46 - Design patterns 1:16:41 - BIPs 1:22:15 - Staying on the cutting edge 1:24:25 - Come and PM for Bitcoin companies Shoutout to our sponsors: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠River⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Unchained⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠CrowdHealth⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Bitcoin Talent Co⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ TFTC Merch is Available: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Shop Now⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ Join the TFTC Movement: Main ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠YT Channel⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ Clips ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠YT Channel⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Website⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Twitter⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Instagram⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ Follow Marty Bent: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Twitter⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Newsletter⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Podcast⁠⁠⁠⁠

what's up freaks it's your boy marty here to introduce this rip of tftc this rip was brought to you by our good friends at river river's the best place to buy bitcoin you can easily buy and sell using the app if you dollar cost average you're not going to pay any fees on those buys if you set up a daily weekly bi-weekly monthly whatever it is you set that up Set it and forget it. You're not going to pay any fees on that. They have limit orders as well. So maybe you want to price snipe and set your buy below where the current price is

or above where the current price is. You can easily do that within the app now. As well, they have auto withdrawals. They really value self-custody at River. So you can give them an address to a wallet that you control. Once you hit a certain threshold, they'll send the Bitcoin directly to that wallet. but they're doing it the right way. They build everything in-house.

They don't have any third-party dependencies. They don't depend on Fortress Trust or Prime Trust or any other third parties. They build their wallets, their multi-sig hold storage in-house. Everything's backed one-to-one, fully reserved. Go to river.com slash TFTC. Sign up today.

Great time to start SAC and SATs. River's a great place to do it. Not financial advice. the store was also brought to you by good friends down the hall unchained it's lively down there right now and then they are strong down the hall they're leading the way in terms of leveraging bitcoin's native multi-sig properties to bring you products that give you peace of mind whether that's their vault product their core product which is a two or three multi-sig where you can old two keys you know one key you know no keys they've got multi-institution multi-signal

partnerships with coin cover kingdom trust they just announced backed last week really leading the way on multi-institutional multi-sig again they have that vault product you can buy bitcoin easily and sell bitcoin via unchained buy send it directly to your vault they have an ria product which gives you peace of mind knowing that your retirement funds are in bitcoin in a wallet with keys that you control you can roll your ira over they have an inheritance protocol to talk about peace of mind passing your bitcoin on is a big problem that many people think of unchained has created an inheritance product a protocol to make that as easy as possible so hit them up Go to unchained.com slash consultation to learn more about what they're building, why they're building it, and why you should be securing your Bitcoin interacting with their products.

They do it the right way, freaks. Unchained.com slash consultation. Set up a call today. This rip was also brought to you by friends at CrowdHealth. CrowdHealth is here to help you bring sovereignty to your healthcare. If you're in Bitcoin, you're finding monetary sovereignty in the Bitcoin protocol. you should go seek sovereignty in other parts of your life health care is one of the pivotal parts of your life crowd health is really attacking the health insurance model which is typically

expensive opaque impersonal crowd health isn't health insurance it's crowdfunded health care you join the crowd health community you pay a monthly fee if you ever go to the doctors you pay the first 500 of that bill then the rest is crowdfunded by the crowd health community they have a bitcoin community and the beauty of crowd health is that you have health advocates so you can get a personal experience talk to somebody to advise you on what to do if you have a health care incident or health event that you need to take care of they advocate for you with the doctors since you're paying out doctors in cash they can negotiate prices lower and they get very steep discounts on everything it's a beautiful thing if you're looking to take

sovereignty over your health care me and my family have done this we've been using crowd health for almost two years the experience has been incredible it's much better than the health insurance industry we were on cobra very expensive crowd health is much cheaper much better experience it's a beautiful thing go to joincrowdhealth.com slash tftc sign up today and you're going to get 99 for your first six months of subscriptions to the crowd health community joincrowdhealth.com slash tftc this report was also brought to you by our good friends at bitcoin talent co a recruiting firm built by bitcoiners for bitcoiners if you're a company in the space looking to hire talent to poach talent from the tech industry from the banking industry

go get onboarded with bitcoin talent co they understand bitcoin they know multi-sig they know mining they know lightning they're not just some run-of-the-mill recruiting firm they're just going to try and gouge you for fees they're actually going to help you find the talent that you need and since they know bitcoin they know what you're looking for they have a flex product as well maybe you don't need a full-time employee you just need a contractor for three months six months to help you on a development sprint a design sprint growth marketing sprint you can tap into their flex network as well if you're looking to get into the space and get into the best companies in the space and you're in the tech industry or the

banking industry or somewhere else go set up a profile with bitcoin talent co get in the mix Get your resume out there and come help us build a future built on a Bitcoin standard. Go to bitcointalent.co. Tell them that TFTC sent you. Enjoy this rip. I believe that in a world where central bankers are tripping over themselves to devalue their currency, Bitcoin wins. In the world of fiat currencies, Bitcoin is the victor. I mean, that's part of the bull case for Bitcoin.

If you're not paying attention, you probably should be. Yeah, it was fun. I got out of the cage. I've been up for 12 hours already. It's only 2.30 in the afternoon. Good luck. Jocko Willock would be proud. Yeah, yeah.

yeah you just run six miles no no that was just up you're just it's just a way that's the first with babies that's the first part just getting up i'll eventually get to uh taking a picture of my watch at 4 30 yeah saying good i can't do it anything before five can't do it i i can't do anything before like 6 30 yeah which is bad i'm trying to wake up earlier yeah it's good for you i think or it's bad for you and then don't do it i'm the opposite i don't get inspiration to write until like 10 p.m at night i stay up i'm trying to get inspiration to write that's why we're here sir i know writing's pretty good this is my this is my accountability uh way to make sure that i hit the publish buttons i'm going to talk about it here and then i'll have no choice

but to publish yeah tftc we like being accountability buddies here yeah yeah exactly at the show in the studio within the commons you missed sean baker last night i did well it's someone's fault but he gave me a 10 minute warning someone else got a notification i didn't get one turns out because i i saw that he had just left yeah yeah parker yeah i said get your ass back here no i love sean i mean you remember when we first started talking like we were in his orbit at the very beginning yes because we were really hot on the keto side of things and then we're like who are these guys that are cooler than us over here they've taken it one step further who's this jacked monster that's only eating steaks he is a monster he crushed my hand last night did he i went to

shake his hand to say goodbye and literally audible knuckle crack on my end you know he's a ut alum i did not know that yeah yeah so he that's how bitstein got in touch with him when he was not a student but like through that connection the alumni network yeah or something i mean maybe not official the official channels but i think that was the initial spark interesting i didn't know that yeah he was in california now he's up in the pacific northwest you're making me think that i'm wrong on this and i could be i think i have a memory that he went to ut for like grad school or something like that well sean if you're listening yeah confirm or deny yeah yeah the allegations of you being a longhorn yeah yeah what's a proud thing

to be right now 10 and 1 who did they lose to they lost to ou yeah it's bad yeah it's not that bad like it's a rivalry game if you see ou coming out of the tunnel last weekend it's pretty bad it's pretty embarrassing you lost to that team yeah yeah i mean both my teams lost to you smu lost him too so i'm uh i am embarrassed i went to ou i went to norman not a great place no you didn't go to school there you went to watch the game i went to watch a game there this year smu played there because texas fans never go there they always play in dallas i went there this year for smu the stadium's like an architectural disaster and i've never seen so many people limping limping a lot of limps gout limps something limps like there's just i i it was like

it was notable like i took a mental note of the fact that so many people were limping it's just an odd thing i'm not making any judgments boomer sooner sooners limping limping in they were pretty happy walking out but yeah they were limping in yeah the football culture down there is fascinating yeah uh i mean it i mean high school's nuts but yeah i need to get to a westlake game so i mean pennsylvania's like that too though i mean my high school is pretty good yeah my high school was terrible small catholic school but westlake yeah that's small catholic school too my brother played with uh drew breeze for a bit drew breeze is pretty good he's okay pretty good is he in the hall of fame yet probably yeah justin tucker's also from

there best kicker of all time he's a hall of famer we have two alumni on the eagles one of them scored a touchdown the other one set up a touchdown yeah epic comeback oh actually eagles starting quarterback uh uh championship winning quarterback also from westlake jalen oh nick foals yeah nick foals yeah yeah they've had a lot of them he uh we will build a statue of nick foals in philadelphia calling a shot at the philly philly play he's so good yeah thank you nick thank you westlake yeah that was the sports ball section of the tftc is that typical i mean i don't think you talk sports too much here matt and i talked about the eagles yesterday that's that's true yeah he's an eagles fan big win he was wearing an eagles hat it was hard not to touch on the subject

yep which is a good segue into this i mean matt yeah so i worked with matt a lot on the stuff that i'm writing about now um which uh just to catch everyone up um i'm trying to get some writing out on basically product development building software and what i've learned over the past shoot 18 years of doing it um mostly mostly as a product manager or something close to it founder of a couple startups um but uh i'm doing it not just to get it out but uh because one of the things that helped me a lot were all those people that you know because you were into the product development world for a long time. It's like the stuff I was reading in from 2004 to 2008 or so was so foundational and getting me started and giving me an opinion on how things are

supposed to be done, but all those guys aren't doing it anymore. Um, and because so many of the Bitcoin companies that I interact with are started by, you know, usually younger people, I want to start getting some of that stuff out that um that uh i feel like i i got a very good education on this well i mean i think anybody in the world who knows your background would agree because you worked very closely with joel spolsky who is yeah yeah consider one of the ogs of the internet age if you will sure i mean he's you know in some cases he's kind of like the original tech blogger you know, before there were really, you know, blogs and people who were just setting up their own web pages. Um, Joel on software was like the only place you could go to read about

someone's opinions on how to build software, uh, him in coding horror, you know, who started stack overflow together. Yeah. I mean, stack overflow is probably one of the most successful engineer. How would you describe it? Stack overflow was an amazing community. Uh, it's a, it's a forum, right? And, uh, the origin stories of it, you know, I wasn't there, uh, at the very beginning. Uh, but the origin story is basically that they were on a mission to, uh, kill experts exchange, which was the, the Q and a forum for programmers, but you had to pay to get answers. And so Joel and, um, Jeff Atwood had started it. I mean, obviously there was a bigger mission than just killing one company but uh this idea uh very early on that this should be out there for free

um and that we would find ways to make that's when i was brought in was to find ways to make money later once it was successful as a forum and um but what was interesting about the those two guys coming together is that they had this huge install base of users because they were probably the two most prominent or widely followed uh bloggers about software development i think we were selling sure they're not just bloggers they also are software developers sure yeah yeah yeah well and joel i mean that's kind of the funny thing is that like i didn't know you could be something um other than a programmer and build software and joel was a program manager at microsoft worked on excel and all sorts of other i think he's largely responsible for getting um

like making excel programmable and getting basic inside of excel great uh great product um and uh but it wasn't until i started reading joel that i was like oh i don't have to be a programmer to do this because i'd programmed my whole childhood my dad was a programmer my brother my uncle like everyone around me were programmers and so rebelling in my family was not being a programmer and then finding out through joel and through his writing that you could do something else and still build software was actually pretty exciting for me. But, um, yeah, I mean, I ended up joining stack overflow and, uh, Joel had been this prominent writer. He had a lot of opinions on how to build software, but, uh, Joel never, you know, as a stack overflow started getting,

you know, bigger, we hit 20 people, 40 people, a hundred people, 200 people up to 300 at one point. um, most of his stuff outside of Microsoft had been very small, small teams. And, uh, there was a point around 2017 or so where we decided, um, that we had to just reinvent everything. Like we, we didn't like, we, we'd read all the books on agile development and, uh, I'd, I'd done all the things that, you know, all the, all the sort of cliche things you do when you're going through like scrum and all that and we decided that we were going to sort of build our own process that was really methodology agnostic meaning like you could throw kanban or scrum or forms of agile on top of it even waterfall if you wanted to but that there seemed to be these core things that

every time we were successful we were doing very specific things and every time we were failing It was because we didn't do one of those things that made us successful before. And we just weren't consistent in repeating our successes. And so we spent a long time on it. The other person that was a huge contributor in the early forms of this was the VP of Engineering at the time, David Fullerton. And so it was kind of our ass on the line. It's like, we got to get better. We got to ship.

We got to ship things that work. Customers need to be happy. We need to make more money. There were a lot of problems. that needed to be solved. Um, and so we just banged our head against the wall for about, you know, three months, uh, coming up with this and then really deployed this process into, uh, that organization. And then over the years, you know, really it started, that was like the Genesis point for it. Um, but, uh, when I moved on to unchained, you know, I was starting to

install this as we started growing as well. We got up over a hundred people, um, uh, as we brought on people like Matt McManus who you had on here uh he was really helpful in helping me change it up a bit um for instance you know at Stack Overflow you can imagine you know it's a forum full of programmers trying to get answers to their questions uh now that's chat GPGPT of course um but uh it's been rough um but we didn't really care that much about quality assurance for instance, not only was it, you know, the stakes, you know, not only were the stakes lower, but our customers, our users actually liked finding problems with our site. It was like a fun thing for them to go onto the meta sites and like, tell us what was wrong. And then as you can also

imagine, when you get to a place like unchained, our customers don't like finding problems, right? The stakes are much, much higher when you're securing people's funds. And so we had to put in a lot more accountability and checks, not just into the quality of the software, but into the, um, sort of unintended consequences of dealing with, uh, you know, disparate parts of the code base. Uh, so, uh, it, it morphed a little bit, you know, through that. And then now at ZapRite, I'm working with John who has a, you know, very different, uh, skillset than a lot of founders. I mean, he's a designer, um, which is a freaking godsend for all of you that have started companies before you'll know that like, if, if one of the founders is not a designer design usually comes

pretty late in the process. Um, and, uh, it's been such a privilege for me to work with him where, um, that part of the product, it, you know, before I was there was, was fantastic and is only getting better. And so anyway, getting back to the sort of origins of this, um, is that, uh, we came up with a system or we've just called it our stack overflow product development process that became the unchained product development process. There's a lot of people that contributed to it other than me, but, uh, I do feel the need to kind of get this out. And, um, really the way I'm trying to describe this to people is that there are invariants for product development, things that you always have to do no matter what. Right. And there's

only five of them right and if you do them consistently you'll ship better software and especially for like you know the bitcoin audience out there that are younger um it can be kind of overwhelming to see these you know huge books i've never read a good product development book ever oh sorry that's not entirely true uh ryan singer's shape up is phenomenal uh from 37 signals they made base camp and base camp you know uh trello did it no trello was us uh that was fog Creek and Stack Overflow people. Um, but yeah, I mean, uh, most of these books are kind of nonsense to be honest. Uh, most of them could be blog posts. That's why Joel and software was so good. And, um, but this, this idea of invariance, what it, what I'm trying to say is that, um, the

most important thing in software development is that you finish the job of solving problems at higher levels of abstraction before you move to lower levels of abstraction. An example of that would be strategy like setting the strategy for your product team or for your company and then lower down would be something like what i call discovery which is where you design and specify very detailed things of what you're going to build and then later on when you're building something your actual lines of code so each one of those represents a descending level of abstraction you're setting strategy, you're writing specifications and making designs and talking to customers and getting feedback on ideas. And then you better know what the fuck you're doing

because you're writing code, right? Less abstract, less abstract, less abstract. This concept or sorry, this way of working is very familiar to programmers, right? They have to think about data models first, abstract, bigger has a lot of consequences, right? Then they might be defining classes and then the writing lines of code, right? So they deal in these layers of abstraction sort of just naturally in their jobs. But the other people involved in building software typically don't think this way. At least in my experience, most of the people I worked with that aren't programmers don't think this way. And when you're building software, I think it behooves you to think like a programmer. And so let's back up and start with the highest level of abstraction,

which is strategy what do you mean by strategy let's use unchained as an example yeah walk through one sprint that you guys did sure go through these levels of abstraction yeah so this is great so even a sprint right is a lower level of abstraction right so it's strategy strategy documents and and the process of creating strategy is usually longer lived right so it it it will live past multiple sprints maybe 10 20 you know or something like that i tend to think that like a good strategy will last about a year right in the software world maybe it's updated a couple times you learn a few things but like again at that level of abstraction you should have put in the work where your strategy can work for about a year what what that really is right is it's not

prescriptive it's not a design it's not a uh it's not a specification but there's just enough requirements to narrow the field of possibilities of what you could build that you get something acceptable at the end. So a good example of unchained would be, we had a strategy that we wanted to build a new monetizable business line and that, that, and that we had made a decision on what that business line was going to be. That was going to be trading right now. There's a lot of things you could do when you build a trading desk. And what we decided to do was do it manually at first, talk to those customers, learn everything that they wanted, right. And then gradually build it into like a automated process. But at the strategy level, right? What we were actually

saying is something like customers and unchained have Bitcoin being stored in multi-sig. All that Bitcoin was bought somewhere, right? So this is its resting place. Why isn't it their starting place, right? So we're going to allow people to buy Bitcoin directly into cold storage with keys that they control. It's a mouthful, but it is a strategy right now. Just saying that there's still a number of ways to actually implement this. And so there's a lot of creativity and autonomy that goes to the teams that are executing on that strategy. But you know, this is also one of the things I see missing in, in organizations is that someone needs to know what the fuck is going on and what, what, what, what you're supposed to do. Right. Um, how many times have you walked into

like an organization and you're talking to one of the programmers or to one of the PMs and I don't know what we're doing. Right. Or like, you know, I'm working on this. It doesn't seem to matter very much. Right. That's a lack of strategic thinking. And there are people that are supposed to set strategy and organizations. Usually it's a founder or an exec or, you know, a senior PM or a CTO or something like that. And, um, it seems that a lot of people, uh, you know, don't, don't follow through on that part of their job. I think, I think it's also very, very hard. Right. And, um, at that, at that high level of abstraction, you might ask like, well, how are you supposed to know what to do? Like, is it just some guy that's this top down,

you know, command and control, you know, style of building shouldn't we do? I have more bottom up. And it's like, it is bottom up, even though it's my responsibility at unchained at the time to set product strategy, right? I would be a fool if everyone's fingerprints on my team weren't all over that thing, right? The job of the person setting strategy is to be in an information advantage to earn the right to author that strategy, right? So if you're not in an information advantage, you have no business in setting the strategy for the company or for a product team or for whatever. So how do you get to an information advantage? Well, you have to talk to customers. That's the number one thing. If you're not in regular contact with customers,

there's no way you can possibly set a strategy to, you have to have a different type of relationship than just a managing relationship with people on your team, right? You have to actually know what they know, learn what they've learned about the product, about the usage, about the anecdotes and the data that are coming through. You have to, um, have, you know, domain expertise and what you're doing. I think domain expertise, it's more and more overrated the further down you get in the layers of abstraction, right? So setting strategy, you got to know your industry, right? Writing code for it, it helps, but it's not as important, right? A good programmer can be a good programmer for Microsoft or Unchained Capital. Yeah. And so it seems like you're getting out

needs to be a lot of communication uh out between the engineering team amongst members of that team internally and then externally to the rest of the company yeah make sure that you're striving towards that same strategy and everybody knows where you are uh in terms of fulfilling the goals of that strategy sure yeah i mean like you know the input is customers, people on your team, the engineers, everything, you know, inside the company, competitive knowledge, all that. The output is now, it ends up, I mean, being a document, right? You know, you create a document that says, you know, unchained trading strategy, right? And you're writing out why this matters to the customer, what the business case is, how you're

going to measure whether you win or lose. Right. And then the really, the hardest part is, is defining the requirements for it. Right. Because at a strategic level, like what you don't want to do is end up writing a bunch of product specifications. Those aren't very memorable, you know, strategies should be short. Uh, everyone on the team needs to remember what it says, right. They don't have to reference the doc over and over and over again. Right. It needs to be, it should be funny. It should be, you know, engaging. It should be good writing. Right. um but memorable is probably the best thing uh that a strategy document should be and how you get there might be you know brainstorm sessions and whiteboards and all this stuff but at the end

you need this artifact this like this thing that everyone is going to be driving towards and it gets more important the more people you have in an organization like it's zap right right now it's easy right there's four of us you know we can we can get together we can do it we can write the dock everyone remembers we're all in the same room every single day but at unchained or at stack overflow or at microsoft right you you get from dozens to hundreds to thousands of people that have to understand what this thing is the more memorable you can make it the better right yeah that was one thing you've referenced towards the end the blog that you haven't pressed publish on yet but at the end you asked uh basically your readers like can you go to your team and ask for

three three pieces of information yeah in fact you just described yeah and then two other pieces so i say at first is like say you're an engineer uh can you show me the specification that you're working off of right did someone write down what you're supposed to be doing um and it that can't be a to-do list, right? People, that's one of the, the tragedies in how people have interpreted agile development over time is they take a Kanban board or, you know, Trello board or whatever, and they put a, you know, a title on it and a description of what they're talking about. And that's their spec, right? That's not going to cut it for the most part. Like you haven't done your job as a product person or as a engineering manager, if that's what, what

someone's working off of. Right. Um, so you take those, first of all, do you even have that document? Right. Then is there a strategy document that that's in service of, right. And then just go ask someone who's tangentially related to the product development process, not the Holy Trinity of designers, PMs, and, and engineers, but go ask someone in marketing because they have a role to play in this process. Right. Um, towards, towards the end of delivering this project this this software this bit of software to the public ask them what are the most important things being worked on most places you can't get all three of those yeah and on the last piece there it's always a funny ongoing battle is usually between sales and marketing

versus engineering like sales and marketing guys are going out and pitching things to customers sure and then coming back to engineering be like yeah the customer wants this go build it and so is yeah setting up this these invariances and internalizing them in the company culture does it prevent that type of problem yeah i mean it's a good process should prevent that type of problem right so i've always found this problem to be the most hilarious because it's such a cliche but it's cliche because it's true right it's like the sales people are selling products that don't exist and they hate their engineering team because they're too slow and they don't know what they're doing at any time. And they know everything that the customer wants and the engineering team

doesn't know anything. And I always say like, that's the whole reason you have a product manager. If that conflict didn't exist, then there would be no reason for there to be product managers. I tell this to PMs all the time is like, if you don't have an engineer, you can't build software. So you have to have them. If you don't have salespeople, no one's going to buy it, right? If you don't have designers, it's going to look like shit. You're the only person who's expendable here your job is to make every single one of those people better and if you can't then you're bad at your job right and the only way you can do that consistently is by having some process in place to make sure that those inevitable you know conflicts arise because again it sounds it

sounds so silly when i'm saying it out loud but like you're on the same team right you know um If the defense is mad at the offense, like, um, it's not going to be a very good culture in clubhouse, right? You're going to have trouble hiring people. You're gonna have trouble, you know, your coaches are going to get fired and that the PM's job is basically to make all of those people better. And they do it by writing things down. It's that simple.

Well, things that they write down is important, right? I talked about the inputs and being an information advantage at a lower level of abstraction from strategy say in discovery right is where you're actually saying okay we need to build a trading product now i'm going to write in very specific detail what that trading product's going to do there's because in the strategy it didn't um necessarily state that um that uh you had to be able to um reach final settlement in 24 hours but you might decide that the only way we're going to win in the marketplace is if we can settle to Unchained's vault faster than you could settle to Unchained's vault if you bought through Coinbase, right? So all of a sudden you have

a new requirement in there. This has to happen and it has to happen within three hours. I don't know, right? Why? Well, because you can buy it somewhere else and you can send that Bitcoin to an Unchained vault. And if that's faster, then people will just continue to do that, right? it'll be at its final resting place quicker which is what people want so that's where you're writing these very specific things about what the requirements are that's not necessarily in the strategy document right and the strategy document should really again it should narrow the playing field of what the acceptable options are for um for the software to do right you you don't want to say like we're going to do trading and then someone goes out and builds a custodial

wallet that says okay people can trade into this now and you're like no that's not so it has to have some specificity but um again you have talented engineers talented pms talented designers um working on this stuff you want to make sure that you're giving them just enough so that they can go be creative and make really important decisions on the implementation layer right and i i feel like i should back up real fast i actually named these invariants right so the first invariant is not wallet, uh, aligns with the strategy sort of atomic unit of product development. Um, I call it think and then do right. But thinking first is very important. And I've been surprised how few people actually think things through before they get going.

What are some examples of people not thinking things through? I'll give you examples on my, of me, right. Is, uh, let's see, uh, stack overflow. Uh, we'll start there. Um, I was really convinced that, uh, we could launch something that stood next to Q and a, and it wasn't just me. It was obviously lots of people, but we as a team didn't think this through that we could launch, uh, something that we call documentation, right. That we had a bunch of programmers writing questions and answers, just putting stuff on the internet, creating these nice little artifacts that, um, that people would use. I thought that we could get them to create another type of artifact, which is long form documentation. And, um, before we, you know,

did the things that I know you're supposed to do, we just started building it. We started writing code, right? This was what the best documentation product would look like. We took it to market and it flopped like bad. And when we went back and looked at our product development process, we realized we didn't do the things you're supposed to do to be successful. Not that we wouldn't have spent time on this. Right. But very early on, because when it was failing, we start talking to people. Why aren't you doing this? You have a bunch of rep on stack overflow. Why aren't you also getting rep over here? What we found is that, um, people like being prompted, right? The types of people that, you know, the answers are very important, right? And, you know,

there's more answers than there are questions, right? We need a lot of people competing over getting good answers because that's how you get good answers. And those questions are very important because it's prompting the person with knowledge to say, hey, come give us some of your best stuff, right? You know how to solve this. Documentation is very open-ended. How does this API work? It's like, well, it's not a super motivating thing. It's a nameless person asking how it works like how do you even know to get started why why do you think you're the person to do this right and we never ask those questions to begin with like at all right um so you know not thinking before you do in this case uh where in writing strategy is like there is no primitive

before it right so the only thing you can do is think and then you can start doing stuff so in this particular case you guys skip discovery well yeah in this particular case we kind of pretended we had a strategy without validating it right and that's an important thing also with each with each one of these phases and let me just say it real fast because i feel like i need to set set this up a little bit better i i think there are five sort of proto-atomic units that all teams need to do in order to ship quality software consistently and that's have a strategy run a process called discovery which is basically the design specking you know user feedback loops a build phase where you're actually writing production code right a quality assurance phase where you're

making sure that that code does what you want it to do and a delivery phase where you're taking that to market right five things right and each of these each of these proto units i'm giving you an invariant name to so that strategy phase thinking then do the discovery phase is don't design without a strategy right and again i want to repeat this because it is the most important part is that you have to finish the work at a previous layer of abstraction at a higher level of abstraction before you start on the next one or else you run into these problems we hadn't finished in the documentation case the the uh the important work in the strategy phase before we were just jumping into discovery and saying this is the best documentation thing we could build

this is what it looks like. These are all the little tools. This is how it's going to integrate into our reputation system. We just got really, really excited over this thing, but we hadn't asked the most important questions. We hadn't solved the problems at the higher abstraction level. So what would the important questions have been to ask? Ah, those are the good ones, right? So like, it's really like, what is the output of a strategy doc? Like what problems have you solved? What decisions have you made? You've usually done about four or five things, just depending on the product, right? Or what you're, what you're building. You've usually made a business case for it. How's the business going to get better, right? Are we going to make

more money or less money? Is this a loss leader? Is this something that's supposed to make us profitable? Do we get more traffic from it? What do you, you know, what's the business case? How's this helped the business? Why do the customers want this, right? And usually you have data and anecdotes leading to a thing that says like, we know there's a subset of people that want to do this or a lot of people that want to do this or a new group of people that want to do this that don't answer questions. Right. Then you want to say, what are the minimal requirements here? Like if in a good metric for a good strategy is that it's so bare bones on the requirements that it does not work if one of the requirements is missing. Like there's nothing, there's no fat on

the bone at all. If you take away one thing, the whole thing falls apart. That's the right level of abstraction there. And then finally you have to have some sort of idea of how are we going to tell if we're winning or losing, right? Those are metrics, KPIs, things like that. How do we know whether or not this software, this feature, this new product line is doing what we thought it would do. If you can say those things, right. And you have a compelling case, not only, you know, can you say them, but when you show them to your team, they get excited. They believe you, right. You've been persuasive, right. Um, then you have a strategy. If you say all those things and you're getting a lot of pushback, did users really say this? Did you talk to anyone? Right. Um, have you

looked at this data about how many words go into an answer versus how many words there are in document in a good well-documented api like um you know these aren't the same things right the motivations are very different right if you get that type of pushback then you second guess yourself maybe you're not ready maybe you haven't solved the problems at that higher abstraction level that you haven't earned your way down to writing those specifications that you get really excited about yeah and so it's a documentation product comparing it to the pure q a the answers were typically shorter documentation is way longer than a way longer it's unprompted um and uh that there were relatively right relatively few people that were interested

in doing it also another weird thing is that it turns out it's someone's job some team's job in really big places like microsoft to write documentation right there are people whose entire job it is to do that when they release a new product api integration whatever it is webhooks and um really if we wanted to be successful we would have talked to them first because they write all the documentation in the world right you talk to them first and say would you do this right what they said i'm not doing this no i'm not doing this twice right how much are you gonna pay me yeah right um you know it was fun look i'm i'm picking on this one example it's not unique i mean like but one other thing that i i think i stole this i'm gonna look

it up after this i think i stole this from peter teal but like the stakes are higher at the higher levels of abstraction too, right? So you make a mistake in strategy and you fail. No one gets better. It's a tragedy. Every single time you've just wasted everyone's time, money, treasure, whatever it is, right? When you fail at lower levels of abstraction, the consequences get less and less, right? You make a bad decision in discovery, right? You start writing code. You have to fall back there. It's less expensive than having to fall back all the way to strategy. You write a bug in the code right and it gets out well you can go back and fix it right it's a lot easier to fix words on a page than it is a data model right um uh and so like you know catching

those problems early on is way cheaper uh because uh the stakes and the stakes are higher so it's like you have to put in the work there yeah and so in terms of timeline i mean you referenced earlier strategy in software development world typically on a year cadence and how do you break that year up in terms like how much time do you spend on discovery how much time do you spend writing code is that predefined once you have your strategy set yeah or that's what i kind of like about these like atomic units and then like the the invariance here is that um you could get through all five invariants in half an hour or an hour for something small, or it could take you months to get through every single stage of this, right? But typically speaking, it really depends

on what role you're playing. I have this little breakout. If you're a product manager, you're going to spend more time at the higher levels of abstraction and strategy and discovery than you are at the lower levels of delivery and building, right? If you're a marketer, you're going to spend more time at the end, the, at the lower levels of abstraction, the, or the higher, uh, if you're an SRE, you know, you know, you know, it differs, but typically speaking, it's like, when I say that the strategy document needs to be a long lived document, it's, um, it's because if things are, are changing a lot at that level of abstraction, then you don't really know what to do. Right. And so how long does it take you to know what to do? I don't, I don't know the answer

to that because it is different in everything right but for like trading for example it unchained that was like a new business line for us it probably took us a couple weeks to convince ourselves that we really wanted to do this and then we spent an inordinate amount of time in discovery a long time in discovery because we didn't feel the need to immediately start writing code we're like well we can hire a trader and they can just start and we can tell our customers you call the trader, they'll execute trades and put it into your vault. And we did that for a very long time. Now it's not necessary that you do that, but we were just really building up that validation that was the case. And also it allowed us to change some things in our code base that would

really allow us to build the automated solution. But I'll go back and just say like, you know, the strategy process in general, if, if the person authoring the strategy document is good at their job they've already they're already setting up the right meetings with their teams they're talking to customers doing all this and you need to inflict a new passion upon your team um then yeah usually a couple weeks right discovery is is the the part where like the designers and the pms are playing the most role uh the biggest role and really it just depends on like the complexity right um are you inventing something new or is there a comp somewhere out there in the marketplace that you really like or are there three that you want to use together an example of this would be

when i first joined stack overflow one of the things we knew was that our messaging system uh where uh for our recruiting site um where you hire programmers from from like the stack user base, um, the messaging system was really janky and bad. And, um, we used a little trick that Joel and I talked about a lot, uh, and David, uh, which is like core versus context is like, is messaging core to our business? Like, is it going to help us win in the marketplace or is it context? It's going to, uh, it's just something that needs to be there, but we don't have to like be the best at it to win in the market. Right. And so something core, you want to spend a lot of time on and something that's context you want to spend as little time on as

possible and so if you use that framing you can say well you know if we're going to in the discovery phase like if we're going to do this right better do it fast because we have more important things to do right that are going to help us win in the market even though this is a necessary component for the for the product to work and then i mean you referenced scrum earlier and so you have the spectrum of what i would define as like liberal approach to product management and then conservative waterfall on the conservative side yeah and more command control on one side yes waterfall more bottom up uh more chaotic um on the agile side yeah and so on the agile side like that's where you get scrum masters weekly stand-ups point i'm trying to get at is throughout this whole

process as you're going down the lower levels of abstraction like one thing that people talk about a lot is like have as few amount of meetings as possible sure like when do you reach checkpoints at every level of traction when you feel the need to be like all right when you get everybody on the same page here where we are yeah you know what saves meetings emails writing well yeah right and having artifacts that are traceable findable you know that relate to the other things at the higher levels of abstraction. So if you write a spec, right, you just put a little link into it and saying like, Oh, by the way,

we're solving this part of the strategy, right? When those things are traceable, you need a lot fewer meetings, right? When we talk about like the waterfall to, to agile spectrum scrum, and I like scrum actually quite a bit. I don't necessarily agree with like the titles people get and things like that, but especially in very large organizations, scrum can be awesome and you can use it on top of our process, right? Um, the invariants are not a methodology, right? You can do waterfall through it. You can do scrum and agile through it. You

could do stage gate through it. You could do all sorts of things. Um, but on that continuum, it's like, yeah, if you want to have fewer meetings, it's, um, the people that are solving the problems at the higher level of abstraction, if they've written those things down very, very well, then maybe they have to talk to two people and those two people have to talk to 10 people. and those 10 people have to talk to 50 people in a typical organization, right? But you, right, by writing that have made everyone's job much, much easier. Yeah. Good writing. Well, and this is, you know, the, you know, I call them the agile list does in, in, in my, uh, in my blog post is like, you know, I've read the agile manifesto. It doesn't say not to write things

down. Right. You know, somehow between, you know, 2000 and 2010 or something, uh, the agile leases of the world decided that, you know, not only is writing things down dumb, but, you know, changing code is fun and easy. Right. And we should just do everything in code. And again, I've read the agile manifesto. It says nothing of the sort that gets perverted into this, like we can never know what we want to do. And so let's just start writing code and hopefully something good comes out of it. It's in fucking insane, right? There's this guy, Jeff Patton. He writes a, uh, I, I, I, I think about it every week. Uh, he wrote a blog post in 2008. Uh, you can tell when I was like coming of age in this, uh, in this, uh, industry, but he wrote a, he wrote a blog post in 2008

called, um, uh, I don't want, I, I, I don't know what I, sorry, let me start over. It's called, I don't know what I want, but I know how to get it. And he's explaining the difference between iterating through a problem and incrementing through a problem. And he has this beautiful diagram or sort of imagery set up where it's the difference of someone thinking about painting the Mona Lisa. And the first person, the only thought they have is a woman in a pastoral setting. That's the only idea they have a woman in a pastoral setting. And they're supposed to make the Mona Lisa. So how do you get the Mona Lisa from that idea? Well, you iterate through it. You don't really know what you want, but you have this process to get it. And so you start

sketching with pencil and you're like being very, very careful about things and you're erasing stuff and you're, you know, changing it up a bunch that's iterating, right? And most people in agile teams are iterating through almost every problem. And then you have incrementing and this person, when they're thinking about painting the Mona Lisa, they have an image of the Mona Lisa, right? So what is this person going to do? This person's going to paint the Mona Lisa, right? That's incrementing. They might paint this corner first, but they're going to paint it very, very well. And they're going to paint over here and they're going to do this. And yeah, they still might do some sketches, but they're going to have a much more direct way to painting

the Mona Lisa instead of the person who had. And so iterating and incrementing, right? They're both valid, right? You can imagine if you have the picture of the Mona Lisa in your head, right? Now say it takes 20 people to paint something because you're going to paint it on a mural or something, right? You're going to be very command and control in how you get from point A to point B from idea to, to solution. If you have the idea of a woman in a pastoral setting, then, um, it doesn't do you much good, right? To just be command and control. You're going to have to sort of tell a lot of people have this image of a woman in pastoral setting. Why don't we try 10 different things to what you think that means? And then I'll pick the best one. And then we'll go on that,

you know, a little bit more in the software world. Um, they're both valid approaches to, to building things, right? What I've found is that there's been this time where everyone thinks every problem should be solved through iteration, which is again, sometimes valid, but what's the onus on the person who's supposed to know what you're trying to do, right? Is there any accountability? Why do you have execs? Why do you have VPs of product and CTOs and things like that? If no one ever knows, can picture the Mona Lisa in their head and then tell you what you want to do, what they want to do, right? I think it's a abdication of responsibility. Now, it's not to say that every organization needs to be top-down command and control waterfall style, right? But

fact that like that's been completely rejected in many circles is insane yeah i mean i remember when i was transitioning from finance to mitch attempt to foray into product management i did the uh ux ui front-end development design boot camp and waterfall was completely like voldemort like yeah not to be mentioned cannot do it yeah it was it was in 2014 so it's like the height of agile scrum absolutely yeah that in that time if it is a dirty word to be called uh waterfalls it's a shop that does waterfall you don't want to work there yeah yeah yeah but that's what uh i really like the analogy you use where it's it doesn't have to be either or you can combine both and what you need to do as a product manager is be a salmon yeah yeah we can swim upstream right so

if you have these like these uh these um you know atomic units the the strategy delivery build qa and delivery right it might sound very waterfall-y and you have to finish all the work up here before you can go here it's like okay but um if we go down one layer of abstraction and we're trying to write a spec and it's not coming out very well, then we just go back to the strategy and we iterate through that loop. And then once you have the spec and you're getting into the code base and you're saying, well, actually what we didn't know is that this is going to cause us to write this gnarly migration, right? That's going to be an absolute nightmare and keep us up all night, you know, on the day of launch, maybe we can do this a little bit better.

You iterate through that problem, right? It's not a linear process of strategy down to shipping the software, it's this constant back and forth, right? And almost every, almost every single project you'll ever do will acquire some form of fallback, right? The important thing is to know what mode are you in, right? Are you iterating or are you incrementing? Because you'll work differently in both those stages. And two is how do you know to fall back, right? How do you know to fall back and how quickly can you get those cycles to go, right? And then when you get really big, right? Where you have 10 different product teams doing 10 different things. You want to pipeline these things, right? You want to be, you know, some teams are going to be at the strategy

stage of their process and another team is going to be at the discovery phase and you want different people going back and forth, um, you know, pipelining through that process, but it doesn't have to be waterfall. It could be waterfall. Um, but if you look at scrum, it's very similar, right there's it's it's it's narrower because even they typically don't get the strategy phase right because it's more about like just a sprint what are we doing during the sprint what is what is the input into the sprint you know prioritization blah blah okay uh write write specs for two days and then we're going to code for a week and a half and then we're going to test it right and um and they have all the different names for the people that do all this stuff um they but even

they understand that there has to be some like structure to how do you graduate from one phase to another? How do you know you're ready to write code even in scrum, right? You're not writing code on day one of a sprint. Uh, typically, uh, you could, but it's not typical, right? You have planning sessions, you have specking sessions, and then you have coding sessions. Um, so yeah, it's, it's, you know, we can swim upstream. We're salmon here. We can go from delivery all the way back to, to strategy. Now that's going to be more expensive and you have to do a good job at each stage, but it doesn't necessitate that. You're right. That a lot of times when I presented this to people, their first question is like, is this just waterfall? And I was like, if you want it to

be, it can be right. But it doesn't have to be. No. And so do you think how many teams out there in the world do you think are applying your strategy right now like what are examples of team shipping good software so i've interacted with a lot that you know everything i'm talking about here is like derivative of something else i've learned right and so there are teams doing variations of this you know for all i know stackoverflow is still doing this a lot of the people that pms and things that i hired they're still there um unchained still doing this sap right. You know, starting to do this, although we're four people, so it's a little bit different, right. I know, uh, I've talked a lot to the cash app team in the past. Um, they have an excellent

product organization, really excellent product organization. It's small, it's tight knit and they get shit done. They do something very similar to this. Um, it's a little bit different in some cases, but like, but like they check the boxes on the big five, right. They just get through it differently than than i typically have done it um microsoft uh has certain parts of the organization that will do this it's too big you know the product teams are too disparate and all over the world but there are certain teams there um especially on the azure team that do stuff like this um uh i've talked to people at facebook they're not doing this not even close they spent what 40 billion dollars on meta it was complete yeah uh is that the worst strategy phase failure

of all time it's it's a really confusing one i'd like to know what inputs the people that set you know mark zuckerberg and his colleagues that set that strategy like because a lot of the strategy is you have to have some idea of what this is going to cost you both in treasure and in time right did anyone start that process and say like we're going to spend 40 billion dollars on this And everyone was like, yep, that's a good idea. Right. I don't think so. Right. And it could end up being a perfectly fine product, but if it costs 10 X, what it was supposed to cost, is it a good product? You know, it's like the product might be good. Customers might like it, but it wrecked the company. Right. And now you can't share, you know, photos on Instagram or

something because you can't afford it anymore. I don't know. Right. Um, uh, similarly, I mean, like, you know, it's, it's kind of like you can't avoid disasters all the time. You have to have some tolerance for risks. I don't believe in like zero tolerance. Right. However, is it's about consistency. Right. And it's about being able to repeat a process over and over again and get reasonable results. So, you know, one of the, one of the ways that I would, you know, check the process on this is that like, um, you do, I don't know, a monthly demo to teams, right. To show them what's, what's about to come out. Right. And in that demo, you tell people, okay, we had decided to do this three weeks ago. Right. We said it was going to take three weeks today. We're demoing the

final version of it. And tomorrow we're shipping, right. You have this accountability set into like some sort of ritual that you go through. Right. And, uh, part of that ritual has to be at the very beginning of saying like how much this is going to cost us how much time how much is going to cost us in time and in money right and if you don't have a concept of that it's really hard to hold yourself accountable yeah yeah and you touched on it particularly larger organizations like creating those pipes across teams that are at different levels of the abstraction layers of these strategies that they're executing on but i think we should dive into this a bit more particularly for the companies in the bitcoin space that are reaching maturity and looking

to scale like what is your advice to product teams that are reaching that that point in their company life cycle where they're going from 50 to 100 to maybe 500 employees yeah how do you manage that growth as a PM? Yeah, it's tough, you know, but, um, the, uh, I'd say there's probably three things that I would advise. One is even if you're not a command and control style of company, right. Hierarchy does matter and accountability matters. Right. Um, and it really should flow upstream a failure in strategy. I say there's always a tragedy, but it's always the fault of the people at the top, right. Head should roll. If your strategy fails at the top, right. there has to be consequences for this. Right. And it's not the programmer unless, you know,

it was the CTO that came up with it. You know, that's going to pay the price for that. Just like when there's a bug and bugs in the code base or there's sloppy, you know, specifications or bad design, you know who to blame. Like when strategy fails, you know who to blame. Do you know who to blame? Right. Who's setting the strategy at your company? Are the founders doing it? Are some early key hires doing it? Knowing who's responsible for what as you get bigger is a pretty big fucking deal. Right. And a lot of times what early startups that are graduating into that 20 to 40 to 50 people is that you've had people that are kind of responsible for everything. Right. And now all of a sudden there's a lot of people and you can't be responsible for everything anymore.

And you have 10,000 customers. And, and so what are you responsible for and what are they responsible for? And then you hold each other accountable. And the only way to do that is to have some sort of process that you go through in order to say like, I'm going to say, I'm going to do this and then i'm going to do it and you'll know i did it because x happened right so you solve that through process and you solve that through through um sort of ownership over certain things the second thing i would say is that um uh don't trick yourself into thinking that like writing things down is a waste of time a lot of early startups are started by engineers right or people designers and engineers and product people you know together and they can say well

it's going to take me four hours to write this down and then uh it's going to take us two hours to code it so why don't we just code it and just do it right and then you run into problems because you haven't documented that and you have a fact and you have all these things but if you had written the spec you could have just taken that out and put it in the fact and everything would have been fine is that uh documenting these things is an important ritual to start even very very early like uh you know john and and parker and i at zap right like you know we write things down we wrote down a strategy we we write down specifications for payment links that came out right and uh sometimes our programmers who are fucking great uh can i'll finish writing something

i'll send it and i'll wake up in the morning and they're like done i'm like well that took me three days you know to like to like do but at the same time it was worth it they wouldn't have been done that fast with that level of quality if i hadn't written it down the way i did right um so writing things down is worth it and creating checklists i love checklists but you know having a kanban board with just a couple things saying i need to build a login system is not writing things down right That's a to-do list, right? To-do lists are not specifications. Um, and, uh, that the earlier you exercise this muscle, the way less problems you're going to have building like a reasonable culture of shipping quality software later on in the business. And of course you're starting this

business because you think it's going to have 50, a hundred, 200, 500 people, right? Make sure you're a part of that or make sure that you're setting yourself up to be a part of it as it succeeds because when it does it can be really fun or it can be rather tragic when everyone hates what they're doing yeah and i can imagine a world in which maybe this is the world in which we live in it doesn't need to be imagined but using zap raising example start with a four-person team writing all these things down you guys are going to be wildly successful get to a 50 100 person team absolutely you can use those artifacts from the early days as sort of like an onboarding thing that you hand to oh yeah new employees was like hey here's how we've done things historically

you can see how we built every part of this product up to this point yeah i i can give you two examples of that actually which is um when when we first did this as stackover before we we formalized this we didn't have much right in terms of like what's the stackoverflow view of how we build software right we had some some blog posts from joel from 10 years prior right But we didn't have much of an identity ourselves. Once we did and we had that documentation, you're right. That goes into onboarding docs. Right. And so, you know, we did all this before I had hired a product team. Right. And then we hired, you know, 20 people on the product team and onboarding those people. Every single person would come back to me and say, like, this was the best freaking onboarding I've ever had. day one, you had, you had all the information I needed to learn how to do this job very, very well. Right. Same thing happened in unchained is that, you know, I'd already had that experience. And so when I joined unchained, it was fairly small, you know, um, you know, 13, 14 people, uh, probably

total, um, you know, four or five engineers, uh, no designers. Um, and so, you know, I didn't come in like, you know, like a jerk and say like, Hey, things have changed. But like over time we built some of that process in a lot of it looked a lot similar to what we did in Unchained. Some of it changed quite a bit. But then when I was onboarding a QA team, right. For instance, or, uh, you know, we hired 15, 20 engineers. Um, it was very easy to say like, this is what's expected of you, right? This is how we do things here. Right. And a lot of product people are very scared to do that to engineers or to designers and say like i'm giving you i'm putting handcuffs on you right we're a stodgy you know business it's exactly i can guarantee you in 80 90 of the cases the

engineers are going to be like thank god because they've all worked at some shitty company before where someone comes in and they're usually working in a panic because they don't know what to do but the results aren't going well and they're saying fix it to an engineer fix it build build a product that makes us money, you know, build a product that converts better really is converts better in a spec. Is that a strategy? You know? And then they go in and they're like, okay, what's going to convert better, less clicks. And it turns out less clicks is worse than more clicks. And they have no fucking idea what's going on. And then they're sitting idle for three weeks because they don't know what to do. Right. There's no strategy. And like, if you can show someone

when they're coming on board the first day, we have a way of doing things here, right? you don't even have to do it my way right i'm just doing it as a way that's been successful to me but if you have an opinion on what is going to work and how we build software at this organization you have an identity around it then yeah onboarding people is a breeze and you get complimented on it and makes you want to do it more right like you put some effort into that and uh you know someone that's coming up is gonna um you know they're gonna make a commit on their first day at work yeah it makes you more effective as a company trying to scale absolutely yeah and that and really that in that moment of like somewhere between 10 and 50 right it's like most of those

aren't gradual usually you're like 10 12 15 people and then all of a sudden you're 50 people because you raised 5 million 10 million dollars right in the in the vc software world at least um not in the bootstrap world that would be more gradual but like you know it's all of a sudden you go from 10 people to 50 people. And then all of a sudden you're at a hundred and you're like, holy shit, that it's been eight months, right? Uh, that's happened to me twice now. Um, and I think it's a fairly common thing, especially in this easy money world where VCs are writing $10 million checks off of, you know, PowerPoint slides is that it's going to be the experience of a lot of people, uh, that are, uh, in the Bitcoin space starting companies today, you know, in 12 months you're

going to be surrounded by 50 people. Yeah. It's funny thinking of all this. I write every single day yeah you mentioned great writer thank you i'm gonna shit on myself here uh because i like it's my goal with tftc to bootstrap like i just have this fascination with bootstrapping the business yeah bootstrap to date and i really want to make this not a large company but hopefully we get to like 10 to 20 employees at some point in the next decade um the fact being i write every day and I've never read written any of the strategy stuff that you're talking about. It's something we only have myself, Logan, Trevor, one other person, but it's something I tried to do.

I'll have to notion a few weeks ago to put some like documentation down. I just, I just fucking lost over it. Yeah. It's a different type of writing, right? I'm not good at the type of writing you're doing. That's what I'm trying to get into is more public, you know, writing for a more public audience. I'm very good at writing for, you know, our company or, you know, what is our mission? What is our strategy? You know, specs, you know, any, I can write all that very, very well. My advice to you would be like, cause I talk to

you a lot, you know, we work 10 feet away from each other is, um, is I know you have a vision. You've told it to me many, many times for what we want TFTC to, uh, turn into is that like, you just put yourself like, you know, one of those lock yourself in a room and I'm not coming out because you could write your strategy in four hours i know i just gotta do it yeah it's tough and then it's going to help every single person that you work with yeah like immeasurably it's going to save you so many meetings it's probably the biggest problem between logan and i is my uh feeling me logan logan what do you what do you think about my communication skills when are we doing rhr this week uh probably 1 p.m tomorrow or thursday we'll see what's tomorrow

yeah i don't even know what month it is so it might be december that's tough a bit it's tough though like juggling all these balls like trying to do the content run the business side um just thinking of like my business and yeah because i do want to add more tech aspects to what we're doing but yep it is you've convinced me and i just need to do it but like lock myself in a room and do it and then that'll have profound knock-on effects do you ever listen to theo vaughn yeah okay so i was i was driving back from dallas um a couple days ago and um uh i was listening to his podcast i can't remember who the guest was but um he's explaining this the exact same problem he's like

man you know all of a sudden you know i'm the boss and you know i know what i want to do with this thing but like no one else knows what they want to do and it's not their fault it's my fault I don't know how to do this. You know, like I'm a standup comic, but now I have a business and I don't know how to run a business, you know? And what he's basically saying is like, I know what this needs to be. He's the guy who has the picture of the Mona Lisa in his head. Right. And what they're doing in the podcast is they're pretending as if it's a woman in a pastoral setting because he hasn't been able to articulate that yet. Right. And so, you know, look, you know, I say the strategy document is, is, is a document that's well-formed that answers

all these questions about the business case and everything. But oftentimes the things that come before that are just as valuable, right? Is getting your team in a room and saying, locking each other in a room and saying like, okay, this whiteboard by the end of this is going to be full of stuff that describes our mission, describes what we're building, describes how it's going to make us money describes how it's going to get our, our viewership up and all this stuff in that black boards is going to look like a fucking mess at the end, but everyone in that room is going to understand it. And then it's just translating that into a written word that's understandable for anyone that wasn't in that room when you did it. Right. Um, I think, uh, I, I mentioned,

uh, Ryan Singer, uh, before, uh, at a lower level of abstraction, maybe this will help is that he wrote something in 2004 called, uh, he's still writing a lot. He wrote shape up like two years ago, but I like his older stuff as well called, uh, uh, something, something, something design patterns. It's about building design patterns where he says like, okay, you want to write a spec, you know, you want to build a new dashboard for zap, right? You know, um, just start with, uh, first thing column bits. What's a bit, a bit is, uh, a module that says how much Bitcoin you've earned. Okay. Bit number two, a module that says how many, um, how many dollars you've earned. Next thing, a module that says how many invoices you've sent out a module

that says how many payment links you have live. You know, you're just listing bits, no priority, nothing, just literally a bit is a piece of UI that's on the screen. How many pieces of UI do you have on the screen? Right? You just list them out in random order. Then it's like next stage group, the bits, right? Take these bits. Are they logically aligned in any way? Well, the, the total Bitcoin and the total dollars, those kinds of sound similar things. We're going to put those together. Bit one, bit two are related to each other. Bit four and bit seven are related to each other. So now you have the bits and you have them grouped and then you say, okay, prioritize the groups, right? So a is the most important thing. B is necessary. C is nice to

have right you group those up and then it says last one is sketch the groups and you just draw little boxes this is roughly where it goes okay i can do anything i can do any web app single page web app or anything that process i can do in 20 minutes right it's just it's it's the way to get out over writer's block i'll do them for strategy docs to list the bits you know they're not pieces of ui but they're points i'm trying to make you know and like just anything you have some people use note cards some people do you know whatever but like this like design pattern thing that ryan singer put together uh you know i i hope he hears this at some point because i think he'll think it's hilarious that someone still uses that strategy from you know 2004 that he wrote almost

20 years later yeah but i every time i give this to like a pm or a designer when we're doing something it's like let's just do a design pattern for 20 minutes together okay let's list this out let's group them. Let's prioritize them. Let's do it. We're 20 minutes in and someone's looking at me and they're like, I got it from here. It's like, it's amazing how much like that level of organization, which is like barely any at all will completely change someone's trajectory on a project. Right. And you can use something like that. You know, I use that mostly at the discovery phase of, um, of this particular product development process, but it can be used in other phases as well like just to get you going yeah it's fascinating process is key yeah it all

seems so simple sometimes i feel very stupid saying it sometimes but when i show it to people that have been doing this for a long time they'll say like i've never done it that way like oh my gosh that actually is very helpful well yeah i think it's the time aspect of actually writing it's funny i wanted to say this earlier but now's a good time to bring it up too like the bent part of the reason started because i was getting inundated with emails and texts like what's going on with bitcoin the price was running and the other part was i was trying to get a product manager job at the time oh cool having never been in industry and the feedback i got when i kept getting rejected from jobs was all right if you never build anything like prove that you can write

about something and so like the newsletter was multifaceted where i could teach my friends and family were asking me about bitcoin about bitcoin and then prove that i could write about a particular product which is bitcoin yeah um think about what i mean like i mean that's really interesting think about like um what amir taki did for the core protocol right with bips right i'm pretty sure he invented the bit process he did it was the first time outside of like you know the mailing list or something that like people were actually writing down with specificity like what are we what am i trying to do next right now it's necessarily different than what you're doing with tftc or what i'm doing at zap right but like even that alone was a huge huge uh change

in uh bitcoin's development a little bit of structure when a huge uh took took the whole project much much further yeah creative process a bitcoin improvement process yeah yeah that's great yeah um i think i think it's a fantastic thing yeah yeah bips what's your favorite bip right now my favorite bip right now i don't know what are they common lightning again i'm watching bolt 12 lips it's changed a lot i was i was in time bolts yeah it's just bolt right yeah i don't know what it stands for but um i don't know i worked in multi-sig for a long time I'm not a lightning expert yet. I'm catching up. Um, but, uh, no, uh, bolt 12, I'm keeping tabs on, you know, uh, right now is my favorite thing, uh, to, to read about. Uh, also, uh, I like the,

uh, I've been implementing, uh, the Ellen address spec and the Ellen URL verified part of that, um, as well, and then sharing it with people that we're integrating with right now. That's how we did the get Albie, um, integration. It turns out there are a lot of wallets that have done that have followed very well the ellen address spec but have not done the ellen url verify part which is that right we need so that when a transaction is is uh sent to one of those we get a message back saying it's it's been received like it's been paid um so uh i've been reading these a lot and like yeah the fact that there are specifications for this like you can't have an open protocol without specific i know that there's no there's no spec for bitcoin or

anything like that but there are specs for bitcoin right like there's not a spec for bitcoin but there are specs about aspects of bitcoin yeah like standards like yeah standards and and bips and bolts and you know all of these it's it's very important to get um you know conformity around this like you need interoperability between the protocol and industry and industry and other industry right and uh having those is super helpful and and we're at a point in lightning in particular right now where there's some very attractive um there's there's a lot of very attractive reasons to be uh very native to lightning instead of doing proprietary apis on chain there's still some problems with that but like in the lightning world it's like

most of these integrations you don't have to do anything proprietary at all to be interoperable with other wallets other companies and things like that it's very it's very nice it's very encouraging oh yeah it's huge um on chain will always have some problems with that um different address structures or it's because the final settlement and the way it works and like you know for instance like the ellen url verify stuff like um we could just you know build an api between us and every single lightning wallet there is right and saying like well you send us you know invoices and then and then we'll show them and then they get paid and then they get deposited in your wallet and then you have to tell us you know back in like we could do that on a proprietary basis

and a few years ago we may have had to right however now we can use the ellen address uh spec and the ellen your uh url verify spec and we can do the same thing on a non-proprietary level that can be repeated with anyone that we work with right and implementing it just so happens in this case to be very very i won't say trivial but it's simple in comparison other things well on bitcoin there's just there's other drawbacks uh you can do it in a native way but uh uh you run into problems like uh there's no communication layer on the main chain to say like hey start it uh this index uh for addresses and you know you know oh they're getting they're getting other invoices paid over here right you need to know about that so you don't try to use

one of those addresses again like there's like little things like that that you just can't really solve for yeah and so proprietary apis make more sense i've experienced this with btc pay server when you have another yes of on-chain invoices that don't get paid in your wallet you get big gaps you get big gaps you got a gap forward and sparrow yeah and then you look on your trezor on your own you don't see it you're like what the fuck and you're freaking out and but it's there yeah yeah you just got to go get forward a thousand addresses to find it yeah yeah exactly but like so yeah there's going to be some like drawbacks there um uh so proprietary apis do make a little bit more sense but i mean there are native ways to do it just give me some xpubs and

i can increment addresses right um it's just when lots of people are trying you know if that if that vault or that that wallet is not specific to this use case then we can't know what's going on outside of it yeah and you run into these types of problems and lightning you can i mean you can completely avoid that like it's not an issue yeah at all god you feel like you're on the cutting edge again coming from stack overflow into bitcoin it was an interesting process for me because uh very much like in very early in my career i i was like well if i'm not writing software like i'll go be an i banker you know because there's nothing for me in the software development world until i found that product management was a thing um and that i was good at

it um similarly for bitcoin it was like well if i'm not contributing to the core protocol there's nothing for me to do here i'm not that interested in building you know an exchange you know a casino so like there's not much for me which is a really weird way for me to think uh it was uh parker lewis actually as as we were talking probably in 2016 2017 that started to convince me that he was like well you know if bitcoin's money what's the product of money i was like i don't know he said financial services of course right um bitcoin itself can replace you know the centralized uh fed and central banks right but there's still going to be a need for products out there that solve the problems that financial services do now. And they're going to look a lot

different. Right. And even if they look familiar and similar, they're going to be based on something that's very, very different. Right. And so it was that realization that made me think like, oh, I do have something to offer here. And it took me a little bit of time because I loved my job at Stack Overflow, like loved it and loved working with Joel and David and everyone there. So I wasn't like super motivated to leave but in 2019 uh uh it would it became i'll say untenable there uh joel had moved on uh just a few months prior i wasn't enjoying it as much without him around um and uh you know you know typical silicon valley new york startup type stuff i didn't fit in too well anymore and uh so to bitcoin i went yeah and thank you bitcoin needs people

that like this and like you know there's so many talented engineers there um they're starting to get a lot of talented product people uh although it was it wasn't the case even four years ago when i started on it well let's end it with a pitch to product people out there it might be on the edge like what kind of mark can they leave on the world if they were to come over and build yeah actually yeah i like this this is a good way to end it is um is if you are talented in the software development world, if you're working at Microsoft and you did something great, if you're working at Google or if you're working at Meta or if you're working in any of these places, right? But you think Bitcoin matters, right? Is there are companies that need your expertise.

We're building software here. And while Bitcoin core protocol is necessarily very different than the types of software you would build at Microsoft, right? The companies that are, you know, the industry building on top of that, the unchains of the world, the zap rights of the world, the tftcs of the world all of us river all the great bitcoin companies it's the same thing you're you're just building software right and so we need talented people that uh have learned from the best um to to be coming over and it's like if you don't think that you have something to offer you're just wrong um and i i i i was in that uh sort of mindset and i was just wrong um is that all these companies need you, um, that they're well financed, um, that they have, you know,

actually I find typically that, um, Bitcoin has, uh, Bitcoin companies that I've engaged with have, uh, incredibly well-suited founders for the stage company that they're at. Meaning that, um, these aren't just people trying to build a new marketplace, a new SAS thing that they're going to flip for $200 million in a couple of years is that they have passion and they have vision for what they want to do. And if you're joining something, nothing, nothing can be more important than knowing what the vision is. Um, if the vision is to go work in San Francisco and to flip your company in two years to Oracle, right? Fine. I mean, there's nothing wrong with that, but it doesn't really get me excited. And I bet you these people listening right now that are working in

those types of jobs aren't very excited. It's very exciting to work on something where the vision is something that you're actually passionate about. So I would encourage you to, uh, know one that your skillset is needed and two that, uh, the conditions in which you'll be coming into are a hell of a lot more fun. Yeah. Oh, I'm jacked up. Yeah. I wasn't expecting this conversation when you approached me a couple of weeks ago, but I'm very happy we had it. Yeah. I'm excited to actually get this published. I'm going to publish it, um, on a new ghost site that I'm setting up. And then also on the zap right uh blog because you know zap right is going to work um it is one of those things where i'm sure i'm going to blink and we're going to be surrounded by 50 people um and um and

uh yeah so we'll be cross posting it on uh zap right and yeah i've paid two zap right invoices this month so it's working yeah it is working yeah it's really funny actually i found um i found a lot of weird people i wasn't expecting dentists lawyers you know using zap right for invoices and then on the payment link side is a little bit more standard it's just you know people that sell things and want bitcoin and we know a lot of the people that do that but um yeah no it's been really encouraging to see you know john's initial you know version of it with with some of the new stuff on here it's like it's it's been it's been a fun last few months uh since big block boom when we launch payment links yeah it's been great i mean see the team that you guys have gathered it's fun

watching you parker and john yeah do the damn thing are we gonna win we're gonna win yeah you have people like john starting companies like this like he has a vision for what he wants right passionate about it like we don't struggle with a lot of the things that typical software teams struggle with so yeah we're gonna win team of killers we're all gonna win we're gonna win you heard it here first Will it's always a pleasure sir thanks Marty

peace and love the king