Capturing phenomena in organizations
Nate: Hey Trey.
Trey: Hey Nate.
Nate: How's it going?
Trey: Good, how are you doing brother?
Nate: Doing really really well. Thanks for asking. So we want to welcome everyone out to the second episode of Craftnotes. Craftnotes is brought to you by Motif Research. So this week in the second field guide that we published, we discussed something around phenomenon, which we talked about in last week's podcast. But really it's the idea that every single business has events, and observable events rather, that are happening all around them that employees are seeing that, you know, every practitioner see is throughout their work and that if caught, and captured and if causation the around those phenomenon are actually investigated then that can lead to really, really neat outcomes inside of an organization. So we're going to talk more about that today and I think as Trey and I have talked a little bit about phenomena in the last the, last little while it's commonly led us to a discussion around roadmaps. And right now the entire product management industry I think is started to be able to realize that product roadmaps are pretty self serving. Trey, would love to hear your thoughts and your experiences, especially in the last several years, around what you've seen as far as road maps and how that's changed a little bit. So let's start there.
Trey: I would say from what I've seen as road maps to your point with them being self-serving is they almost always change, especially once you get past two, three months out in the future. And I think part of that is because of all the unknowns associated with laying out what you're planning on building in the future when you're playing on delivering to the market.
Trey: A lot of it comes from we're going to talk about today is that lack of understanding phenomenon and then following up with the questions that need to be researched and answered. So I think there's just a lot of unknowns when that gets put together. And so of course it's going to change and I think that's why outside of product organizations it's easy to see a lot of skepticism around a roadmap that gets put out.
Nate: Yeah. I think it goes back to one of the discussions that we had last week. And that you and I actually had throughout the week is really around how organizations are commonly a lot more output driven than outcome driven. And one of the things that Trey and I were talking about was the fact that a lot of organizations in the last decade and two decades for that matter have started to make this shift from physical products to digital products. And I think roadmaps lend themselves really really nicely to something like a physical hardware, you know, production line because you're forecasting the amount of units or that, you know, which version of a particular product you're actually going to be releasing which has to be able to have some implications around what will be stocked. How it will get out to you big box distributors. Those types of things, but it really doesn't lend itself very well at all to this new wave of digital products. So roadmaps are definitely a legacy item that I think comes from product development of yonder years of when people really had to be able to project with Precision what they would actually be producing. And now it's been skewed into this almost projection of what future value propositions are actually going to be built. You're really outlining and being expected to outline what your company's entire strategic initiatives are which is just crazy to think that people are being expected to look out to three years in a roadmap and try and forecast not only how existing efforts will perform, but things that haven't even been released yet will perform and expect that none of their initiatives are going to change in that meantime in that current period of time.
Trey: Absolutely, and you mentioned this in the first field guide that we published a few weeks ago where if you're putting together a road map. And you're using conjectures based on the past that works fine. If nothing is changing in the future.
Trey: But that is completely false. And so going with that understanding of we're going to pinpoint in three months, six months, nine months, a year from now, what's going to be valuable in the market given all the changes going to happen just doesn't make sense.
Nate: No. No, in my career alone in the last seven or eight years I think about just the technology landscape shift that has happened. I didn't know a lot of companies that weren't heavily monolithic in nature when it came to their architecture in SaaS companies. I think most of the organizations that I had either worked with or knew about we're very monolithic. And microservices weren't new and, you know, Martin Fowler and others have been advocating for them for decades. But I think that the shift in the entire industry adopting them and you know, a lot of the technologies like Docker and Kubernetes and just back ends as a service like Firebase all these different things that are actually making a lot easier to be able to change the technologies that you're using. Think about that alone. The technology shift that's happened in just the last ten years and then think about what types of product offerings that's enabled year over year over year for these these new age of digital products I should say. I don't think it would even be possible for Netflix to be doing what they're doing with the margins that they have 10 years ago, at the scale that they are at right now without the given technology. So I think there's a huge, there's a huge component of just how asinine it is to expect that nothing is going to change, to your point Trey, and that technology isn't going to change, and that we can have the super forecasted vision into what's going to happen down the road. I think it's crazy. I think it's unfair to be able to expect that from any practitioner that is inside of your organization.
Trey: Absolutely. And even if you look at just in our short careers the culture change in even marketing. I feel like especially in the tech area. You think three four years ago everyone was doing webinars. And that's slowly died out and now everyone starting off with podcast. I think about that where like 18 months ago I thought podcast weren't even a thing anymore and someone tells me "Hey, you should listen to a podcast." I'm like, a podcast? Like from when I was in high school? And...
Trey: Just to see that change in just that amount of time that was not even necessarily a technological shift because the technology was already there but a cultural shift. Those things are always changing to your point. Not only with technology but also on the cultural side.
Nate: Yeah. So we look at this concept of roadmaps. I think not only was it a shift from the age of physical products into this digital product era, but there's also this sense of how products used to be built where in waterfall development you have this very rigid process of how you have some senior executive who's really coming out with this long-term vision of what they want to try and accomplish and executing against that and watching that taper down through all these different layers of bureaucracy and delivery and I think it's also just an attachment to how things used to be built. And it's really not a representation of what works best. It's not a representation about best practices today. And the other thing I think happens a lot, to your point, of how things change you think about the number of startups that leverage roadmaps to be able to sell futures. Right? That they have these things that they know they want to come out with. They're compensating again competitors they know they don't have features X Y and Z, like user administration, a lot of the complex permissioning that maybe an older competitor has had the time to be able to actually ship out the door. But a roadmap, you know, if you can communicate, "Well in this year, this is what we're actually going to be working towards so, you know, if you If you jump on today, then you know, you can really expect this kind of iterative release cycle. You'll see these new features come down the road." I've seen that several times in several different startups where that's over-leveraged. And the funny part is is that 90% of what's on that road map never gets delivered because priority shift.
Nate: Yeah, I think as we've talked a lot about roadmaps, it became pretty clear how apropos this conversation of phenomena is and how it can really change the way that you think about what's going to be coming down the road as far as what needs to be learned about what questions need answers versus trying to anticipate and look so far around the corner that you're almost making a 360 around what features are actually going to be built a year two years three years down the road. So I think there's a, there's a pretty clear connection for anyone right now that is questioning, or trying to, or is wavering on their conviction around roadmaps. And think we commend you, and we offer up the fact that there's a really a better way to be able to do this and that it's identifying and canonizing phenomenon inside your company. And making sure that it's able to be accessible and accountable for those that are going to be building new products.
Trey: Absolutely and let's take a moment and just describe and define what a phenomenon is. In the field guide we've defined a phenomenon as an event that can be observed but normally has a cause that is unclear or difficult to explain. And so if you are engaging with customers or engaging with the market, if you have a business that's heavy on engaging with your prospects that eventually become customers. If you have a sales organization, implementation team, account management organization or even if you just have a product team that is engaging and already connecting with customers, you are seeing phenomenon already. You may not be thinking about it that way. You may be thinking about it as getting customer feedback. But really it's a phenomenon. It's observing and seeing things that are happening that you don't have a quick explanation for and one thing I want to make a point of here is that I think organization see phenomenon more than they think they do. I just think we get so caught up in the process and the habit of jumping to a hypothesis. We see something and we say to ourselves, "Oh, they're doing this behavior because of this condition or this environmental variable." Instead of taking a step back and realizing, "Look. We're seeing this happen. We're seeing customers do this, or users try to accomplish this, and we don't really know why." And I think that's a fundamental part of understanding phenomenon is accepting and beginning with the idea that you don't have all the answers. You don't have all the data and what's more important from understanding phenomenon, instead of jumping to a hypothesis, it's more important to understand what questions you need to answer today to be able to move forward.
Nate: Yeah, I think to modify what you're saying though just a tiny bit is if you start out with this sense of, "I don't have all the answers". I think, to your point, you're going to be less likely to be able to jump into hypothesis or some sort of conjecture around what actually needs to be done, but I think the first step that needs it happen there is you need to go find out the cause. What's the causation behind this phenomenon that you see? So let's say you have a customer that calls in and they have some sort of misperception around how some sort of feature works and you're getting inundated probably, you know, four or five times a day about this particular misperception. And this is being used incorrectly, you know, some feature in your product is being used incorrectly you're hearing about often, frequently. There's one way to handle that which, is to your point Trey, people jump into this nature of I'm going to go try and alter this feature immediately and just test based upon my own guesses of how to make that work And just see if that makes some sort of measurable impact. The second alternative way is actually trying to understand what's happening. What are they doing that leads them to that moment of misunderstanding and misperception. There's probably some context that you're going to learn that's going to enable you to actually build something that's better than what you could have guessed about. There's a reason, there's a mental model that that user has, and each user subsequent in previous that has ever experienced that, that they have that needs to be understood. You have to go understand why they're doing that. If you can explain the causation, it's going to enable you down stream to be able to do some really cool things, you know with whatever you try in the future.
Trey: Absolutely. I think it opens up the ability to be able to discover true hidden opportunities that others aren't taking the time to discover, and along the same lines you're mentioning about someone calling in and giving that direct customer feedback. I think when you're trying to shift your mindset from a customer feedback mindset to understand phenomenon is, especially like I said, if you're working directly with customers, you're going to get so many times customer same things like, "I wish your product did this. I wish it did XYZ. I wish it filled this use case." And you may even go as far to say something like, "Well, tell me a little about that use case. Tell me a little more about what you're trying to accomplish and why you'd want this specific feature". But when you take the perspective of phenomenon like you mentioned then you can take a step back and really try and understand. What was the user doing up to this point that led them to run into this issue where they felt like that the proposed solution should be a feature that does this. And other things we need to know around that issue before we can even make a hypothesis around it. And I think that's just something has to begin with this understanding of a phenomenon and what it really is.
Nate: Yeah. The interesting part there too is that if you get to the point where you're actually capturing these phenomenon, researching the causation, building hypotheses around them, you know, seeing an impact etc. The thing that you need to realize is the competitive advantage that you have is that the rest of your competitors are actually most likely working off of one of two, you know, ways of doing things the first of which is feature requests. To your point Trey, like they just get inundated with these these calls and emails and support tickets that are coming from their customers with. "Hey, I really want this" or "I want this" or "I want this" and product managers are sifting through, you know, these queues of requests and they might even do some interviews with people to be able to understand their requests and these really well intentioned product managers, and well-intentioned customers probably have some really great lines of communication. And they end up building based upon feature requests. The second is kind of what we talked about last time, which is you have some sort of executive or, you know, highly paid person in the room who is making conjectures and executing or expecting the organization execute on their vision and is heavily withdrawn from the context of what a customer needs and wants. So you you are working in juxtaposition to those two things. That's how you're going to excel, to your point Trey. If you understand the context and the causation it's going to enable you to be able to do things that are truly unique. As I think back at my career right now the best and most successful products that I've ever created are things that a customer never asked for. They never directly asked me to be able to do, you know, these certain features or products but I understood their context so well and I could empathize so well with what they were going through and I understood what was leading them to those points and I could explain and understand their behavior in such a way that I understood and can predict what would happen when they behaved, enabled me to be able to craft solutions for them that weren't expressed. Weren't articulated ever as a feature request or whatever it might be. That isn't to say that customers can't articulate their needs. They absolutely can. We're just saying that they're often things that you can do for a customer that they will not articulate for you and they'll be extremely valuable, you know, products and features.
Trey: Absolutely and I really think that is what real Innovation is. Like you mentioned where you understand and have deep empathy for the market and the user and what they're experiencing or what they're trying to accomplish. But what makes you different from the user who's giving the feedback is that you have the tools and resources at your disposal and the understanding of what's possible to provide a solution. And so many times we're familiar with what's possible and what can be done and we start doing things that are new and could be done. But without having that deep empathy and that deep understanding you really can't get those great discoveries like you mentioned. One story that Nate shared and this field guide that was a great example of this process of observing phenomenon and then acting accordingly, diving into a questions answered and researched to find a solution, comes from Airbnb. Back in the day in 2009 when they're first getting started. They were seeing really great growth in a few initial markets and they decided to expand into New York City. Once again, this is back in 2009. So we didn't have the fantastic megapixel camera phones that we do now and what they noticed when they first expand to New York City. Was that they weren't seeing the same amount of growth as they did in their other initial markets. And with the founders decided to do was they decided to book Airbnbs with 24 different locations in New York, just to try understand firsthand what was going on. Why was New York City not doing as well as their the markets? And come to find out one of the biggest things they realized was that the photos that the hosts were taking in New York City of their Airbnb's, the quality of those photos was really really bad and the co-founder Joe said, "The photos were really bad. People were using camera phones and taking Craigslist-quality pictures. Surprised! No one was booking because you couldn't see what you're paying for." None of those hosts had the camera coming you needed, once again back in 2009. It's a different day and age now. But back in 2009 the host didn't have the camera equipment they needed to take great pictures. And so what they decide to try was to start bringing in freelance photographers to come in and take great pictures to really show off the listings. And they immediately saw 3x increase in the bookings, and what this has led to for Airbnb is creating this large freelance network of over 2,000 plus photographers that now Airbnb contracts with to go and take pictures of host locations to be put on Airbnb. And what I love about this example, is that the co-founders, Joe and Brian Airbnb, recognize this phenomenon that the listings in New York City weren't doing as well as compared to other markets and, what we've talked about before in our previous podcasts and in the other field guide as well is that they could have gone different routes. They could have gone the hypothesis route where they could have got a bunch of people in the room and sat down and started making guesses in terms of why this is the case and people could have said things like, "Well, it looks like the descriptions aren't as thorough as they are in other markets. It looks like we haven't been in New York City as long as other." You know, "Maybe the average cost of hotels isn't comparable in other markets. And so people just would rather still stay in a hotel in New York City." All these things could have come out. They also could have commissioned an analyst to go and find all these metrics to compare between their different markets. For example, they could have dove into what's the average cost per square foot of Hotel space in New York City versus San Francisco? You know, how many conferences are held in New York City versus San Francisco? How many people visit these locations based on tourism? What's the average household income of people who are visiting those locations? They could've just gone on and on in so much data and tried to come up with conjectures as far as why those two markets are doing different. But what they did instead was realize this phenomenon, realized they didn't have the answers, and then go and do some real in-context research and understanding to be able to find that issue. That it was just the pictures. Now, you could say that, well, if they're doing the hypothesis approach someone in the room could have said, "Hey, it looks like these photos aren't as good as the others. They're not high quality their poor placement." But one, what are the chances of that actually being a hypothesis that would be thrown out?
Trey: And then two, what are the chances that that hypothesis would win and that someone would actually try this?
Nate: I've been trying to think all afternoon about how that would have surfaced in data because what's going to happen is you're gonna do, you know, this giant select star on everything that's coming through New York City and you're probably going to be looking for, you know, null data values that are coming through on this New York City locations. And every one of them probably had photos. It's not that they didn't not have, that they didn't have any photos. They were photos there. They just weren't any good. So is it any data and analysts actually going to be able to thinking about, "I wonder how those photos actually look." No way. No way would that have happened.
Trey: Exactly. Even if they did it's like how would you even try to quantify that right? Like how would you objectively be able to say, "Well I would say on a scale from 0 to 9 that the photos here in New York City are 6 when the other ones are hard 7 and a half, you know, like how did they even get to that comparison?
Nate: Yeah, the other interesting part is, you know, hopefully you don't take this as being too nitpicky, but you mentioned that you know, they they started contracting with freelancers. They actually didn't even do that immediately. The first thing that they did is they used one of their own cameras and went to dozens is as many as they possibly could why were there there. They went into as many hosts homes as they could and took the photos themselves. So you have these two co-founders that before they contracted with anybody before they did anything. They truly practiced this Occam's razor hypothesis.
Nate: What is the simplest, to use what I think is the true meaning of the word ,the leanest, idea that we can do here to be able to improve these photos? They went around took these photos themselves. And in lieu of them taking those photos saw 3x increase. So they hadn't even started contracting right? They hadn't even started paying these high-wage freelancers to be able to go in and actually do this. So before they even executed on this large network, they had taken the time to be able to in his as little investment but with as much predictability as possible they tested out their idea, right. Their hypothesis here. I mentioned this in the article, I love this story because it's a perfect example of theory building inside of an organization.
Nate: It's textbook. They saw the phenomenon. The phenomenon was, "Hey," like you said, "the bookings are different. There's a delta in bookings compared to other markets." That's a phenomenon. You know, full stop. Look that straight in the face and you say, "We don't know why this is happening. We're gonna go investigate into why this is actually occurring for specifically this market." They do this in-context research. They find out that it's photos. They build a hypothesis that maybe if they take the photos themselves that will make an impact. It makes it 3x increase in short order around those bookings and now they have an explanatory framework. Around the influence and ability for photography to influence their business in the future. So by taking the time and the energy that many people would argue was heavy or inaction, right? Like they didn't actually try anything yet. But by doing so by making that investment to be able to try and understand what was causing that. They had something that would actually perpetually influence their business forever. That theory still holds today. They still focus on imaging every single way. Now this freelance network is massive. So they've obviously seen the impact that it has and they have a theory that they can execute for the life of their business.
Trey: Absolutely, and it comes back to that point you said as far as it being predictable. They just know now that every single market they go into, and now they're everywhere, but like you said those images have to be high-quality have to be positioned well or it's just not going to work out.
Nate: Yeah, absolutely.
Trey: The next thing you could probably thinking while you're hearing all this is what does this mean for us? Like what can we do in our organization to really start understanding phenomenon and capturing it and more importantly canonizing it? And in the field guide we talked about a few key ways and one of the things that is discussed is actually bringing together a physical meeting where team members, employees can all bring together phenomenal they've observed and be able to share that with everyone and. Nate makes a really great point here that I really like where he talks about that so many people in the organization are going to be observing phenomenon with customers and even though they're not directly going to be having impact on what's going to be built and what the plans look like for the future in terms of product. They are still going to have valuable phenomenon that they're capturing and that's going to be helpful to those product teams that are trying to understand the phenomenon. Trying to understand what's good for their users and for their market. I think this is a great thing to be able to bring into play and more importantly, frame-up what a phenomenon is so everyone's kind of being helpful in that meeting. But Nate do you have any more comments or thoughts on how you do that well and how you can get started in an organization where you're not used to capturing phenomenon or talkin about it in this way?
Nate: Yeah. You have to be able to train others what it even means to be able to observe a phenomenon? In previous jobs one of the ways that I've seen this done is we saw this be really effective with customer support and customer success. When somebody would have a problem or an issue, we taught them to be able to really drill into what was occurring. And not so much just take it face value what the customer is saying. The customer is going to be heated. They always are and for good reasons, but they're hyperbole should not influence prioritization and oftentimes it does. Oftentimes the sensationalism of how a customers is acting in response to not having a particular product or feature influences what ends up being built. That's super unfortunate, where if you can have people inside and throughout the organization actually understand what they're looking for and what they're trying to accomplish, they start communicating to you differently. They stop talkin about. The things that we don't have and they start talking about the things that they have observed and they get excited about whether or not those things have been learned about. So I remember a CSM that I worked with who brought me, this this phenomenon and would really almost ping me semi-weekly about "Hey have we learned or heard anything about this?" Have we sent out a survey? Have we done customer interviews? Have we done an on-site visit around this?" And it was really exciting to see them get excited in that way and to be able to actually be on the same page as us around what we are trying to accomplish in the way that we're trying to accomplish it and they they shared you know, the vision with us. They shared the understanding of how we should actually go out and solve that problem versus, perpetually coming to us and telling us about the features that we already knew we didn't have. So I think you have to make sure that people inside the organization understand what this actually means. What they're looking for. To your point, yeah, it's super important, you know, that's democratized across the organization. As far as the meeting goes, one of the things I was really concerned about when I was writing the article is whether or not it would come across that I was suggesting that product practitioners, organizing meeting and then, hear from the rest of the organization because that's not that is not what we're advocating for. You know, not only would that just be a terrible experience for any product practitioner, but it would be scary to think that could be influencing future and current priorities. So what all I'm trying to say is that you create a conduit for the phenomena that you're going to be missing even when you're directly reaching out to customers, even when you're doing on-site visits, they're going to be things that you're missing that are actually more particular to the business model oftentimes, I mean again Airbnb is a perfect example of this that the lack of bookings, it was a revenue problem and really not, directly user experience problem per se. That example there I think this goes to say like if you have a team in finance, in customer support, whatever might be there are things that are occurring for them that they're observing that you need to be able to know about. So this is purely just a funnel for you to be able to understand and see what's actually happening around the business so that you can make the right decisions.
Trey: And to emphasize what you mentioned a while earlier about the hyperbole of how upset the customer is, I feel like they almost gets exponential based on the account value as well. So when bringing these things forward whether you're in sales, customer success, or support and you throw out the red alarm of, "Hey, this account is really upset with XYZ and we need to do this about it because we can't lose this." That's not the right way to approach it. Like Nate mentioned, we need to be able to do is take a step back. Try to figure out what's going on. Describe and be able to understand what the customer's trying to go through to understand that phenomenon like what is being observed, and then to start thinking about, "What do we need to learn about next." And that's the information needs to be captured and canonized and whether you decide to use some sort of ticketing system, whether it's something like Trello or Jira, to have some sort of template to help those individuals be able to think through these kinds of questions when they're recording the phenomenon, I think will really set up well when you do have a meeting like this. If you use that to bring things like that together, and I think you mentioned this in the field guide as well, but even being able to have team members to submit phenomenon beforehand and then being able to filter through the ones that are just saying, "Hey, I want you to build this" versus saying, "Hey, we've observed this kind of behavior and this kind of response across these types of users." Two very different conversations and two very different approaches.
Nate: Yeah. Absolutely. I think I think we're slightly still just a little weak on enforcing the idea that if you're going to do something like this you have, you must, you must restrict what's coming through that meeting. You have to be very rigid about what you're asking for. That you're asking for what the observed phenomena was and they're going to need to understand what a phenomenon is to be able to articulate that to you. So you have to do some education. Anybody that wants to participate in that meeting must understand those things. If they're going to submit something and come and present it they need to be able to present to you in a very specific format. While that might come across as overly prescriptive. This is uncomfortable and this is new to the majority of the people that would be involved in anything like this. So you have to show them the way. You have to help them get guided through this process of understanding how they're going to be surfacing these really amazing events that they're observing and I think if you can do, that if you can find a way to help people actually surface what's really being observed you're going to funnel some really cool opportunities that you normally wouldn't have seen yourself.
Trey: Absolutely. I think maybe I need to mention a little more, I've been hitting heavy on the feedback directly from customers, but more important is just observing what's happening. So when you are engaging with customers or you are on site, for example, if you're working on like a documentation tool, and you see some behavior of users writing things down on paper and posted notes first and then like putting it in a stack and commissioning to someone else. Hey now, it's your job to put this in said product we've purchased. That's something that's observable and you take that phenomenon. That would be something extremely helpful to bring to the product team to be able to understand and to dive into.
Nate: Yeah. The other common place where I think a lot of phenomenon are actually observed is usually within looking at the engagement to performance of an existing product. So if you're looking at how a product is being used and who's using it how often they're using it. There's a lot of practitioners that are very reactive to that type of data. That they immediately try to be able to you start. just doing whatever they can in any way possible to go to influence that. Honestly, a lot of growth hacking I think advocates for that, not all, but there's a lot of growth hacking that advocates for this. I vehemently disagree with that concept. If you can look at what's being observed, what you're actually seeing there in those analytics and then do the work to understand why that's actually happening which means that you might have to be able to pull a segment or cohort of those people that are behaving in that particular way and then ask them about their behavior. Interview them. Get them on the phone. I've done hundreds of interviews that are like that, and not once has anyone ever felt uncomfortable or betrayed by the fact that I understood how they're behaving. Which I know is actually a common fear around this. So if you're listening and you actually feel that way, I promise you that you are not going to, you know, lose a user or a customer just because you understand how they use your product. If anything they're going to feel actually advocated for and they're going to see to the fact that you're actually trying to understand them. Please don't dig into that and worry about that and tunnel in and, you know, and worry so much about that. But you need to understand the causality. So when you look at that and you you accept the fact that it's been a phenomenon, I think that's the first step in the battle of knowing that, "Hey- there's there's a little bit of work here to be done before I start reacting to this data."
Trey: Absolutely and to your point you mentioned this already before but when you make this switch in this transformation from building feature request logs and roadmaps, you make the switch from that to capturing phenomenon, you do see this transition in your company or team in thinking less about what your product doesn't have and caring a whole lot more about what questions you're trying to answer and what you're trying to understand about your customers and the market to set as that guiding star for what you're going to build next.
Nate: Yeah, and the other beautiful thing is that you start wondering what theories do we have right now that could explain this? Is there anything that, do you have any theories that we've that we've built in the past around our users behavior that would help us understand this. That's where you start to see like we talked about last time where you end up paying the full cost no matter what that if you think you're going to be able to get more value by incrementally building conjectures over and over again versus actually trying to build a theory up front you're wrong. Because you're either you're going to have to learn all the elements that build up to a theory in some way. And you might do that iteratively and you might do that, gradually but you're gonna have to learn it and it's either going to come through multiple failures or it's going to come through you actually taking the time to understand your customers. It's going to happen one of two ways or the third is you fail, right?
Trey: Absolutely. Absolutely you run out of money.
Nate: Ye ah. So if you accept the fact that, "Hey, I'm gonna pay the full costs no matter what." That if I expect that incremental, value building and that, you know, conjectures are going to marginally be advantageous you're wrong. you're going to find a huge amount of positive outcomes on your business if you just seek to understand your customers and understand their behavior.
Trey: So sit down. Buckle up. Observe some phenomenon, and get ready to build some theories.
Nate: That's right. That's right. Well, that's probably a good note to end on so, this next week for the field guides, we're going to to be focusing on prioritization. So we've talked about actually capturing and canonizing the phenomena. We're going to talk about how that should start making its way into how you think about prioritization inside of your organization. So we'll be talking about that next. Please take some time, for our listeners so far, to be able to comment and give us feedback again we're using Anchor. Anchor has some amazing features to be able to respond to a podcast and actually ask questions. We're more than happy to be able to field some questions and answer them as we go. Also a little plug for an experiment we're going to run here as well. This week we're going to be starting something new called Sidenotes, and Sidenotes are going to be most likely 3-minute conversations with either Trey or I talking just kind of real briefly about a very specific principle. We're gonna try that out this week, this first Sidenote is probably going to be around outputs versus outcomes and why that occurs which we kind of hinted to today. Get ready for that. And yeah, just leave as much feedback as you can. We're excited to be able to speak with you.
Trey: And if you like playing the email game shoot us an email at email@example.com.
Nate: Yeah. All right. We'll see you later Trey. Thanks, man.
Trey: Take care Nate.