Causative verbs in English, let, make, have, get, and help, from espressoenglish.net. The English verbs let, make, have, get, and help are called causative verbs because they cause something else to happen. Here are some examples of how causative verbs work in English sentences. Let's start with the word let. It means to permit something to happen. The grammatical structure is let plus the person or thing plus the base form of the verb. We do not use to with let. For example, I don't let my kids watch violent movies. Again, the correct structure is let my kids watch. Don't say let my kids to watch. That's incorrect.  Our boss doesn't let us eat lunch at our desks. We have to eat in the cafeteria. Oops! I wasn't paying attention while cooking and I let the food burn. Don't let the advertising expenses surpass a thousand dollars. Remember that the past tense of let is also let. There is no change. The verbs allow and permit are more formal ways to say let. However, with allow and permit, we use to plus the verb. For example, I don't allow my kids to watch violent movies. Our boss doesn't permit us to eat lunch at our desks. Now let's look at the verb make. This means to force or require someone to take an action. The grammatical structure is make plus the person plus the base form of the verb. Again, we don't use the word to. For example, after Billy broke the neighbor's window, his parents made him pay for it. Remember, we use the base form pay and not to pay. My ex-boyfriend loved sci-fi and made me watch every episode of his favorite show. The teacher made all the students rewrite their papers because the first drafts were not acceptable. When using the verbs force and require as an alternative to make, then we must use to plus the verb. For example, the school requires the students to wear uniforms. The word require often implies that there is a rule. The hijacker forced the pilots to take the plane in a different direction. The word force often implies violence, threats, or extremely strong pressure. Our next causative verb is have. This means to give someone else the responsibility to do something. There are two possible grammatical structures, have plus the person plus the base form of the verb, or have plus the thing plus the past participle. Here are some examples of grammatical structure number one. I'll have my assistant call you to reschedule the appointment. The businessman had his secretary make copies of the report. And here are some examples of grammatical structure number two. I'm going to have my hair cut tomorrow. In this structure we don't say who cuts the hair, but the hair will be cut by somebody. We're having our house painted this weekend. Again, we don't say who does the action. We focus more on the object, the receiver of the action, our house, which will receive the action of being painted. Bob had his teeth whitened, his smile looks great. My washing machine is broken, I need to have it repaired. In informal speech we often use get in these cases. For example, I'm going to get my hair cut tomorrow. We're getting our house painted this weekend. Bob got his teeth whitened, his smile looks great. My washing machine is broken, I need to get it repaired. We can also use the verb get to mean convince or encourage someone to do something. And the grammatical structure is get plus the person plus to plus the verb. For example, how can we get all the employees to arrive on time? In this sentence the word get means to convince or encourage the employees to arrive on time. My husband hates housework, I can never get him to wash the dishes. I was nervous about eating sushi, but my brother got me to try it at a Japanese restaurant. The non-profit got a professional photographer to take photos at the event for free. Finally we have the word help meaning to assist someone in doing something. With help we can have two possible grammatical structures. Help plus the person plus the base form of the verb or help plus the person plus to plus the verb. After help you can use to or not both ways are correct. In general the form without to is more common. For example, he helped me carry the boxes or he helped me to carry the boxes. Reading before bed helps me relax or reading before bed helps me to relax. Again both are correct but the form without the word to is more common in everyday English. If you want to learn advanced English grammar check out the advanced English grammar course at espressoenglish.net. This course has 45 lessons that will help you master the advanced details of the English language. And it also includes personal feedback on your written English. Visit espressoenglish.net for the advanced English grammar course. Take your English from good to great.


um um um um um um um um hmm... is a group of words or a singular word acting as a grammatical unit तु यवनि फ्रेस कु जब हम दवलप करते हों और उसके लिए हम खासcidos यह खास बॉल्ल्लिए of grammar के use करते है और किया है कि यह different words तु है वो सिल तूर्फें यह different words मिलखार तो एक sentence यह एक unit कतो पर use होते है जिनको, for instance, the English expression the very happy squirrel is a noun phrase which contains the adjective phrase very happy you need to do adjective phrase that very happy and the phrase can consist of a single word or a complete sentence this is not a phrase, it can be a word or a sentence so verbs, the phrases are different noun phrase, verb phrase, adjective phrase, adverb phrase, prepositional phrase i.e. in different parts of the speech which are used to make different shapes so we need to keep these things in mind while doing phrase development so phrase development refers to the process of constructing and refining a group of group related words that form a meaningful unit in a sentence i.e. i have already told you that we need to connect sentences with subject, verb and object in English language, this is required to connect sentences along with this, different parts of speech are used to convey the right sense i.e. to combine these two ideas i.e. we combine these parts of speech of grammar along with these ideas and these specific functions are used so phrases can include a variety of words such as noun, verbs, adjectives, adverbs and preposition and can be used to modify, complement, or complete other parts of sentence i.e. they complement, complete, add, i.e. in their meanings and in the same way, in the same way, we combine these different phrases the development of phrase involves selecting appropriate words which convey desired meanings and they are arranged with a logical order and then the grammar is ensured to convey the right meaning or sense and in a larger context, while making a sentence if we look at the phonetics these are speech sounds phonology words morphology phrases and sentences syntax literal meaning of phrases and sentences semantics pragmatics meaning in a context of discourse i.e. a language and used pragmatics context of language effective phrase development is important for clear and coherent sentence construction if the language speaker uses the right grammar and combines the right sentences then he can communicate his intended message so in phrase development, we see examples like once in a blue moon piece of cake bite the bullet break a leg so cat got your tongue i.e. these are different phrases noun phrase is a tiny mouse adjective phrase is very tall principle phrase is suddenly by tragedy prepositional phrase is on the table under the table verb phrase was reading action is added in verbs only occasional gerent phrase is eating selfish quickly so infinitive phrase is to swim in dangerous water so these are different examples of phrases and different types of phrases i.e. examples of phrases i.e. clear how we do phrase development and how we use it in our language and for this we should know the correct rules grammar and the correct sentence we should know the sense and we should follow the grammar


a technical writer with SUSE and an advisor to Ovesa. But before working in the open source space, I was into the systems engineering side of things within IT. And honestly speaking, my segue into open source was with Kubernetes and not Linux, which is funny because I worked on a lot of Linux systems and was responsible for a lot of Linux administration in my jobs, but my segue like I said was via Kubernetes. And I'm here speaking to you really because I stood on the shoulders of giants and it was because of the mentorship opportunities that I have had personally that I was able to grow in my career and in my journey with an open source. So I'd be remiss if I didn't give them credit, but I also recognize that despite all the mentorship programs, initiatives, whether formal or informal, that we have within the technology space, mentorship opportunities or programs or initiatives, or what do we call them? They suffer from various problems because despite all the good intentions that go behind these initiatives, there are certain factors that we still don't recognize as hindering the progress or capturing the effectiveness of these initiatives. So with this session, hopefully what I aim to do is to walk you all through some of the common breakdowns and hopefully I'm here with some actionable take aways to sort of prevent them in your respective projects or wherever you're implementing these initiatives. So hopefully that sets some context and let's dive right in honestly. Now I know that everybody here knows what mentorship is, but I'll be speeding through this one. And typically in a mentorship effort, what tends to happen is there's a person or a set of people who are newcomers to the whole ecosystem whether it be the technology one or wherever else this initiative is taking place and there's a person who is slightly more experienced in that whole setup. So there is maybe I wouldn't say it's a bi-directional exchange here, but it's more of a initiative where the more experienced person takes on the role of a mentor to hand hold and guide the new entrant to the ecosystem in and help them navigate the ecosystem. Now mentorship in open source isn't really widely different because it's obvious that there is still a mapping between the mentor and the mentee. That's definitely there. However, given the flux that open source is always in, mentors are typically folks within the community who have slightly more experience. This doesn't necessarily translate to someone who's more older than you or who has more years of experience in the industry, but it's literally a person within that ecosystem who is more experienced and who has been around for longer. So they know a little better about how to navigate and how to best position a person within the ecosystem so that they can contribute more effectively. How it is also an additional community aspect factored into this loop. So what does that exactly mean? Typically in traditional mentorship setups, what happens is you have a mentor, you have a mentee and the interaction is pretty much limited to them within the whole program. But unlike in a traditional format, what happens in open source is that there's also the wider community that's factored into this loop. So to draw from a personal reference when I worked with a son on the Google season of docs, I was not expected to just work with the three sets of, not three sets, three mentors that I had and interact with just them. I was expected to seek community feedback from other people who previously worked on the code base, who were working on the code base, who were users of the code base so that I could effectively contribute in that mentorship program. This included previous participants of not just Google season of docs, but other outreach programs as well, other staff within CERN and other academicians who were accessing the documentation. But like I said, due to the inherent voluntary nature of open source, mentorship opportunities within open source aren't effectively able to provide the support and onboard a mentee as effectively as we would want to. Now I'm not saying that it's like a 100% failure rate, that is not what I'm intending to convey. But we could do things better. There's always room for improvement. And what are the reasons behind those failures or those breakdowns that we speak of? So these are the four areas where you see mentorship programs typically failing, whether they are formal or informal in nature because not every mentorship program has like a titular mentor, at least in open source. I went through many mentors who weren't titled as mentors. They just really were hand holding me throughout the process. So I had initially planned for this whole session to be like a curation of research papers, but I realized that that would be no fun because it would be very dry. And honestly speaking, nobody would really gain any benefit. So what I chose to do is to go through each of these breakdowns and draw from personal references again so that it's more real life, as they say. And hopefully that gives you an idea. And I'm also going to then share what actually worked for us, both not just as a community, but as a contributor as well. So hopefully that is able to give you a better picture of how to go about navigating that breakdown. So the first one up is procedural breakdowns. And the owners of this majorly falls in the community or the mentor is what is a common belief. But it's not just that. Honestly speaking, when I say laying out the scope and context, it's not just from the mentor's perspective or from the program's perspective that that should be an initiative. There should be a self assessment from the mentee side as well as to what they are capable of when applying for a mentorship program or while seeking out a mentorship. Because that's something that is grossly undervalued as a thing that goes on during mentorship program. People don't know what they want to be mentored in. People don't understand what are their skill sets. People don't understand where they are standing currently and where they want to be. And of course, there is a whole community aspect to it as well which we shall get into the next couple of slides. But that initial self assessment by the candidate who's seeking out mentorship is absolutely essential. And without that, both the mentor, the mentee and the community in general is setting themselves up for failure really when it comes to this whole program. So when I started out personally, I remember that I wanted to do a bunch of things. I wanted to learn every cloud native technology that was there on that landscape. And that was putting it very mildly.  I reached out to everybody I could find who I could ask for work from but that was a mistake on my part because I should have clearly assessed what was my capability and what I could offer and what I could bring to the table and what I wanted to grow into rather than just taking on a bunch of responsibilities and spreading myself through. But there is this whole concept of also welcoming people into the community. There are not just cloud native tech but outside of cloud native tech wherever these mentorship programs are in place, there is a whole concept of welcoming people into the community and showing them around. It's just plain courtesy when you look at it. But that's an important step and it's a step a lot of us miss out on primarily because who wants to be actually the person who actually hand holds them and shows them hey, this is the place where you start off at, this is what you do. It's just plain courtesy and it sounds like rubbish when I'm actually saying it but it's that important step when you go into a community that you actually tell people that the new engine that this is how stuff works. Now, every community cannot afford to do that in with every contributor. Every single person cannot be mapped to one person which is why within the Kubernetes community which I'm part of, at least that's the only experience I can speak to. So within the Kubernetes community we have a named role for this. This is a new contributor ambassador. Now, it might not seem like much because how does it make a difference when the first person who actually comes and interacts with you is warm but it makes a really, really big difference when that person is actually very welcoming and is offering you help. I can speak from personal experience because had my first interactions not been warm and welcoming and were they all cold and rude, I probably wouldn't have been speaking in front of you all today because it's the people who matter at the end of the day. The community is made up of people, right? So honestly speaking, it's the people who matter and the tech comes second and that's something I always believe in. Again, going back to my efforts, it's my mentors, unofficial and official, they basically pointed me to resources where I could learn more. They urged me to take on more responsibilities and sometimes even nominated me for positions I didn't think myself worthy of. They did that with my consent of course but this is something that I think really helps. Having that human touch, having a face to actually onboard newer members, it need not be a role that is exactly similar to this but there should be someone who does this and whatever name you choose to give it is obviously upon you. It helps the connections build and there is proof, several research papers who go into measuring retention capacity for people who come into open source, new contributors who enter into open source, those folks have confirmed that a positive socialization experience at the start of every new contributor's journey actually does help in retaining them within the community and we all know how difficult it is to actually have voluntary contributors within open source so it's a challenge and this is just one of the ways obviously to address that. Now honestly speaking, that's one aspect of welcoming is one aspect but once you're in, once you have completed your first task, what's next? Because you wouldn't know where to go because you're new and it's like you have to go down a rabbit hole to find your next good issue or good task that you can work on. So having a new contributor ambassador and all of that roles help but also having a signpost maybe in your documentation or somewhere in the avenues where you interact really helps. Now, if I actually take a step back here and go back to my own experience, having within the Kubernetes community, again, there's a contributor ladder. Sorry. So the contributor ladders in general again help the contributors aspire to a higher role or a higher position within the community. That's one side but even when you are talking about different areas within the same community, all these issues wherein you need help and you need, if you tag them appropriately even within the avenue where you're troubleshooting these issues, those are good ways to actually attract contributors. So having a contributor ladder is just one way of gamifying the whole experience for a new contributor because you believe it or not, all of us here, even though I don't personally like playing games on the laptop or wherever, we're all living in a very gamified world. Slaying payments, getting that title, getting a promotion is all setting off the same pathways in our brain. It's like ticking off the checklist and moving on to the next level. So contribution ladder is one of the ways that you can achieve that gamification within your project. But like I said, for all this to happen, that very first step where the new contributor assesses themselves is extremely important because all this comes into play when you are aware of what you are able to do and will be able to do given the appropriate tools and the technology. So context and scope, whether it's on the side of the community or whether it's on the side of the person who's actually seeking mentorship is absolutely important. Now, scope and context in informal pairings is easy because you have that personal channel, you can just reach out and clarify that, hey, this is what I was intending to do and I think I might have gone a bit astray. But when it's like a one to many mentorship, it's going to be a bit more of a problem. And when we talk about formal mentorship programs, I'm sure that the person obviously has responsibilities more than just mentorship. It's going to be being an experienced contributor, their day lives, their day jobs, their normal lives. All of that comes into the picture. So how do you actually help with context setting in that case? And how do you help define the scope of the program? Now, when you talk about setting the context and forming the scope, first understanding the contributor is necessary. So having that first initial conversation with the contributor and understanding where they come from is necessary. Obviously you can only go so far as to trust their words and then go with an actual assessment. When I started out with the Google Season of Dogs program at Sun, they actually just gave me an assessment and told me to write a whole thing about the RUCO system that I was working on. And I had to actually, because I was involved with the Kubernetes community and that's something they saw, they were asking me to describe RUC on K, its installation. And because it was documentation, it was very relevant. But having that first stage of assessment really helped them understand what I could bring to the table, not just with respect to describing the whole system, but in understanding whether I could actually describe it succinctly and make a document out of it. So that's one thing. But there's also the concept of an entry level barrier when we come in, in most technical communities. In, you know, as of now, I think one of the biggest entry level barriers that newcomer faces when joining an open source project in the technical spaces learning it.   But understanding that that needs to be learned and documenting that somewhere is an onus on the community members, saying that these need to be the prerequisites that you need to have before you come in. I agree that there is, that is a significant entry level barrier to cross. But that needs to be there because otherwise there is going to be a whole, you know, there's going to be a whole influx of contributors who have nothing to do and aren't able to contribute effectively and a whole cohort of maintainers and mentors and experienced contributors who are taking on more than their share of work. So setting the expectations right at the beginning is important and that's why having that initial assessment, self and with your mentor and, you know, documenting your entry level barriers clearly is important. Now I've, you know, stayed quite a long on the procedural part of it. But let's look at a more familiar area of breakdown which is technical. So I have been personally traumatized by the phrase but it works on my machine. That's something that gives me knightness because honestly I've been in production support for way too long. So it's been the bane of my life to listen to people say it works on my machine when, you know, millions of dollars are stuck in payments. But I guess that's a topic for my next CFP. So technical breakdowns are common because, you know, not everybody has the same workstation and workstations really differ in the kind of, you know, specs that they support, whether it be, you know, the computer architecture, the software that can be downloaded, et cetera, et cetera. I mean, I don't need to go too deep into that. But to, again, go back to myself, I had a gaming laptop that could not even install a K8 cluster when I started out. And it significantly impeded the way I actually started out with Kubernetes. So that's where I think stuff like ephemeral dev environments and browser-based IDs come into the picture, right? I know that these are very recent things that have come into existence. And these folks have not paid me to say any of this, but I think it's a very great way to integrate more accessibility into our projects. I don't know if there's a hardware equivalent of this, really, so that's a question I, you know, I have personally for people who are, you know, working on programs, or mentorship programs that involve hardware as well. So I do not have any idea about that. But for software-based stuff, such things are a boon because it helps irrespective of the, you know, slowness of the internet connection or the spec that you have on your laptop. You're able to navigate or set up a cluster or do whatever it is. Now I've gone too deep into Kubernetes, so every time I say something, it's setting up a cluster that first comes to my mind as an example. But in general, that's something that really helps in the software side of things. Now, that was a very brief stop at technical breakdowns. The next one up on the circle was personal breakdowns. And it's an interesting focus point here because we're back to talking about humans again. So it could be both from the mentor as well as the mentee perspective. But I will be focusing on the mentor side of things here because I think it has a slightly more impact as compared to the mentee one. In the first couple of slides, I did say that mentorship and open-source has three broad components which are like the mentor, mentee, and the community. The mentor is a slightly more experienced person and then mentee is actually seeking to gain more experience. Given which the mentor probably has more elevated responsibilities and a day job and a life, whether voluntary or paid, that's a lot of things on one page. And honestly speaking, if the past couple of years is anything, is any indication of the future, all of this is going to be extremely difficult because at least it has taught me the value of time management and context switching. The reason being when you're required to context switch between a day job, between mentorship, initiative that you're a part of, between the open-source, other open-source tasks that you must complete, your personal life on the back burner, all of that comes together and it's very easy for you to spiral down into burnout, especially in remote setups. Now, a lot of us have moved back to offices but with remote setups I feel like that's a very easy to spiral into burnout if you do not have an effective strategy for time management and context switching. I would rather not recommend context switching at all because it's honestly a very ineffective way of dedicating of dedicating time and of blocking our time.  Another thing is that with personal breakdowns, there is this problem which is actually not a problem if there aren't way too many mentees but one to way too many mentorship is a serious problem in general if there's already a lot on your plate. So I know that a lot of mentors don't have a say in how many mentees they take on but that's something that needs to be changed if you do have the power to do that because unless you actually are able to take on that much load you should not be because neither is it going to be good for the people who you are mentoring or for the community for whom this effort is in place. It's not going to be, it's going to be a lose-lose situation for everyone involved. And obviously not for, it's definitely going to be a lose-lose situation for you as well. And I think this is something Nadia Iqbal who wrote the book, Working in Public sort of covered very nicely. It's not aimed at dissing any mentorship programs but coupled with the fact that most of these programs don't actually do a good job of scoping out and that initial context setting how they go about doing it is not really done well. There is an added pressure on experienced contributors and maintainers to course correct and go above and beyond for the mentees which is okay up to a point but after that point it becomes a burden on the experienced contributor or maintainer because they obviously are doing so much more than just the mentoring opportunity. But now that I have covered all of this, this is like the last section of my presentation dealing with interpersonal breakdown. And throughout these past two years, I'm sure some of these are very relevant given that we were all remote for a really long time. It feels like a long time now. Whether it be struggling with time zones and not being able to attend that Zoom meeting at 4 a.m. in my time or struggling with keeping up with the cultural difference, it's difficult because we're all very different here and we're all probably going to identify with different genders, religious preferences, dietary preferences, et cetera. I'm sure it must have been a very tough task even with this conference which in itself is a community gathering to create a safe space for all of us to gather together.  It's going to, you know, something is going to slip through the cracks. But if anything, I'm honestly, you know, here to say that all of those inclusion efforts that you're having, those outreach efforts that you're having for diversity candidates, they matter. Because without those, there are going to be several people in the dark who are deserving of opportunities. And it's on us as community members to actually voice those out and be the change we want to see. And that's a little cliche, but yeah. But when it comes to us, what can we do about it? This is something I've repeatedly heard because, you know, people struggle with meetings all the time. Like I remember when I started out as a contributor in Kubernetes two years back, there were no APAC time zone friendly meetings. I come from India. And it was a real struggle because how am I supposed to sit up till 12 a.m. to just attend one meeting? Eventually because, you know, we didn't seem like we were getting out of a pandemic anytime soon, there was a provision made across, you know, the work, different groups that were there as part of the project to account for APAC friendly meetings. But that was again not enough because what if a person couldn't actually make it to the meeting? What if a person had their daily life come in between? What if they couldn't account for, you know, an in-person meeting? So we had this whole system brought up, at least in the groups that I'm part of, wherein we also, you know, had an asynchronous meeting effort underway. Over and above which we also accounted for asynchronous presence. So suppose if you had to actually attend a meeting and couldn't make it and you wanted to, you know, voice out some points, there would be an agenda documentation ahead of time wherein you actually listed those points and those would be spoken to in the presentation. Sorry, not presentations. Those would be spoken to in the meeting and you could view a recording later. If any clarification was required, you could ask about it on the Slack channel or wherever you feel comfortable. Especially when you're talking about mentorship opportunities, it's not going to be that I'm going to find a mentor who's right next to my house. That's definitely not gonna be possible. So if you are a part of a program and you have the power to make the decision, always, always account for the fact that there are going to be a sync meetings. Always account for the fact that you might need to cancel some of those Zoom and Google Meet invites that you have sent out. Additionally, in open source, we go by consensus seeking rather than consensus driven decisions. There's a difference between the two. The reason being consensus seeking decisions aren't going to be hard and fast on the fact on whether you have given consensus or not. And it is especially important because when you're talking about mentorship opportunities in open source, you are engaging the new entrant into the community. You are embedding him into the community. So it's essential that they be familiarized with the fact that you may have different points of view. You may have a difference of opinion, but there is going to be a collective discussion about this and something that is seeking the consensus rather than a person saying that this is the way forward and that's all, that is not the case. And it's difficult when you come from a setup that is not really the same as open source because this was a paradigm shift for me when I realized that decisions here are consensus seeking rather than driven because in our day jobs, to be honest, that's not the case. And last but not the least, I think having inclusive language mandated as part of your daily interactions is a key. The reason being, it's essential to not use harmful language in general. It's difficult for a lot of people out there and using that language is simply not done because now we're a global community. So standardizing inclusive language and using that language within your communities is exceptionally important. And I think the Inclusion Naming Initiative does a fantastic job of that. I've linked to the website and my resources section so you can have a look later. And some of the ways you can actually do the, you can actually mandate inclusive language is by using bots to regulate inclusive language usage. It's there on the Kubernetes Slack so I know that it is possible. But yeah, that brings me to the resources slide which I was talking about and this whole deck will be up and shared once I get home and it'll also be available on my GitHub repo. And with that I think I've reached the logical end of my presentation and thank you so much for your time everyone. I hope you have a fantastic time at the event. Bye-bye. So also I will be open to taking any questions. I forgot to mention that. Yeah, please. Yeah. Should I start again or did you hear the first part? I could catch it but I think it would be better for the recording if you could start again. Sure. So when it comes to mentorship the mentee usually enters a new technological area that they're not familiar with. What I've found is that there's a challenge of creating a task for them like an initial task that's vague enough for them to allow them to investigate but not too specific to give them some room, you know. How do you or if do you have any methods that you recommend to teach them to, you know, think methodically and break down tasks effectively whilst at the same time you're navigating the challenging world of open source? Yeah, that's a very good question and honestly speaking that's a very subjective case to be honest because like you said it's going to be every entry into the ecosystem is going to have a different level of skills that they bring along with them. So when I'm assigning tasks or when I'm actually recommending people to work on specific areas of the project what I first do is I go and you know have that conversation with them as to what they're comfortable doing because I understand that you know even comfort levels vary with respect to a particular technology and it's not necessary that you know everybody starts at ground, at level zero some people could be starting at level 15 but still be comfortable with doing only level zero tasks because you know they're intimidated. So having that first initial conversation helps that's one thing. The second thing is providing them with the resources that they can actually you know start doing tasks with so based on the conversation that I have with them if there are specific resources that I can provide and there will be because there's a lot of documentation I don't recommend that all the documentation is good but there will be some documentation in your project that can help them get onboarded to the level of the tasks that they choose to actually I mean that you've chosen for them to work on and last but not the least constantly checking in with them and by constantly I don't mean pinging every hour but checking in with them and figuring out if there is you know anything that I can personally do or you know patching them with another resource within the project who probably you know be able to solve their problems better those are like the three steps I majorly follow because I understand that every like I start off I start off my contribution journey in open source with docs but I understand that not everybody wants to contribute to docs so that's that's what helps Thank you very much Thank you Oh I think we just have one minute so I'll be able to take the last question if there's anything or else I'll be at the Suitsa booth for a bit and we can chat there as well


So, yeah, just before I get going, I'm going to be talking about being a PM in an early stage startup. I'll kind of come onto why that's the case, but before I do that, I'd just like to maybe tell you a little bit about me. So I'm Jason, I'm a product owner at Zava. Zava is an online healthcare company that helps people get prescription medication when they're unable to get it through their normal GP. So that might be because it's a treatment offered on the NHS or perhaps their GP is closed or you can't get an appointment or you're embarrassed to go and see them face to face. So imagine embarrassing bodies. I've been a PM for around seven years. I got into product when I was at PayPal and since then I've been working at a bunch of different companies at different sizes and at different stages of development. So I've really got to see the spectrum from working in a kind of big valley company which was around 10,000 people all the way through to working in a tiny startup with less than 10 people. So I've kind of worked at some medium companies in between them as well. So I've got this kind of wide experience and I wanted to talk about being in a very small startup because that's an area that I often don't hear people talk about. So early stage startups, right, you've probably all seen this kind of curve before, right? This is what early businesses kind of go through. So they start off by, if you imagine this is like customer numbers or some other metric like revenue or something, life starts out very flat and in this period you're trying to figure out what you do, like is the business going to be successful and at some point you hopefully hit this point here which is like the hockey stick, the growth curve, right? Now most companies you're aware of are somewhere over to the right of here. So PayPal is like miles to the right, probably plateauing in terms of growth. Other companies I've worked in are like kind of still on this growth trajectory but I'm really going to be focusing in on this area here. Now you might be wondering why I focus on this area. The first thing is that many, there's a lot of product kind of education out there to help you understand like the craft of product. So there's things like, you know, how to do prioritization, how to look at roadmaps, jobs to be done. There's a whole like really well-written bunch of stuff around product but not so many people talk about what life is like in different kinds of companies, the different cultures that are there and how this changes the role. So that's what I really wanted to focus on. Really start-ups, because start-ups are going to this interesting place. You know, we're in an incubator now and there's like loads of start-ups probably just outside. And so I wanted to give a little bit of insight into what life is like there. And I think that's particularly relevant for PMs. There's a lot of PMs are quite entrepreneurial, you know, they're thinking about maybe even starting their own businesses at some point. And so I just wanted to get a bit more of a flavor of what life is like there. All right, so the first thing is like why join an early-stage start-up.  And the first is really around impact, right? So people go and people think mixed different aspects of impact. So I think of impact in two ways, like impact to end like customers, like people's lives and impact that you have on the business. I'm kind of thinking customer impact and kind of what I call agency, which is like the impact you have on the business yourself, right? So you're one big bit of a small organization. You can have a much more kind of leverage in terms of what happens to that organization and whether it's successful. So with the first one kind of customer impact, again, I think of this in two dimensions, like how deep are you impacting someone's life? So are you saving people maybe like one minute every year or are you kind of saving their life? Like that's kind of the spectrum of like how much depth of impact you can have. And the other scale is like number of people that you impact. So are you impacting one person like hundreds, millions, billions? There's a two levels of impact. That those, I don't think you're as likely to get in an LHC startup. It's very small entity, so you're not going to get the scale that's there. And depending on the kind of problem that you go after, you may or may not get that kind of depth of impact as well. But quite often startups are going for new problems that no one's working on. So I think there is the opportunity to do that. But just be aware that like those ones you can get in other organizations. Agency though, on the other hand, you really do get that.    The second thing I wanted to talk about was kind of bureaucracy slash speed. So again, these two things are kind of intertwined. People think that going to a startup, you were to move really quickly. You know, the kind of Facebook motto of move fast and break things will apply more if you're in a startup. And certainly from a bureaucracy perspective, that's true. You're going to be able to move much faster in terms of making decisions. There's going to be a couple of other people you ever run things by. So you'll get to move really fast in that regard. And there's also, but when it comes to actual speed of moving your product, et cetera, along, that's going to be a lot more varied than you think. On the plus side, there's like a lack of kind of any legacy, anything, which means you can just go and do everything Greenfield, which is great. You can move quickly. But there are other benefits to being in a larger company. So things like marketing, for example, if you want to spend any money on marketing, you might not be able to do that in a small company. In a large company, you might get that. Also, things like distribution. Distribution is really important for making something successful. And if you're in a large organization, they might have distribution channels you can enter, so you might be able to go to market much faster than in a startup. Also, team members. I don't know if you guys have the plethora of different skills in your team, but you might be down a designer or some other key skills that really help you move forwards. And that can mean that you actually end up going a lot slower than you would necessarily think. So speed is more nuanced, I think. A couple of the others. So Greenfield Project, doing something new, that's obviously there. You're creating a whole new company, hopefully doing a whole new thing. That's great. And that really leads on to the next one, which is a sense of adventure. Like, I suddenly had it when I was in a small company. You've got a real good camaraderie. There's only a few of you.  You do that to an extent in larger companies, but you end up mixing with lots of other people as well. And it's a sense of view against the kind of world in some ways. So that is really great. But the last one, I think, is the one that I was most interested in. And certainly my main motivation for going somewhere small. And that was the kind of learning opportunity you end up getting. You get to kind of do so many different things. That kind of decision-making aspect means that you get to try lots of different things as well. And you get to kind of do it all yourself. And that's, I think, a really great way of learning things and really cutting your teeth. So the bottom one, I think, is one of the best motivations for going somewhere. So that's maybe why you wanted to go and join the startup. And the next question to ask is, why is the startup hiring you? It might not be something that you think about that much. But your classic startup looks something like this, right? You've got your founder CEO. You've got a couple of devs. You've got maybe a business person, maybe a couple of other people that are in and around. You never see a product manager, do you? There's no PM in most startups in most startup culture. And that's because the founders are often playing the role of the PM. So they've got some kind of market insight, or they've got some kind of customer insight. They've got some knowledge about something that allows them to set up the business. And that puts them in a good position to talk to your developers and guide the kind of product that's being built. So in many situations, you won't find a PM in an organization like this. The time that they hire a PM is when they're starting to scale up. So they're getting bigger. There's the CEO, if they've been playing that role, starts to have to do lots of other things. They need to look after marketing teams, maybe a sales team, operations, lots of other realities start to kick in, and they need to delegate the role of the PM to a dedicated person. If you're going before that scale-up stage, you're probably being brought in because the founders have no idea about product, design, and technology. So they're bringing you in to work on that. Now, this is, again, interesting because that brings a whole bunch of expectations that are likely to be on you. So they're going to probably think that they're hiring this, which is probably a project manager, right?  I once worked with a PM who spent about the first 18 months of being in a product manager role, going to loads of meetups, a little bit like this, to try and figure out what it was that he was doing. I don't know if you've ever tried to explain it to friends or family. It's not an easy thing. Everyone thinks project manager. Yeah, they're the one that produces this gantt chart, makes sure you hit everything on deadline in time.  The only reason they're hiring a product manager is because the developers have probably said product manager, or they're talking to investors, or they're getting some port from somewhere else, and they're saying, what you really need is a product manager. But they've got no real idea of what this is. They're going to expect you to come in and to take control of the tech guys, maybe talk techie to the technical people. They're going to try and make sure that their ideas get carried through and turned into features and don't get lost within the tech team. They're going to hope that you work through their roadmap that they've already set up and deliver this big vision that they've got to investors.  I'm this intersection between design, business, and technology. I'm really customer centric. I focus on problems, not solutions. I'm strategic, and I know how to get close to our customers. Now, this is all true. You do need to do this, but just bear in mind about the expectations they have. Because whilst you work towards this, you need to make sure you meet the expectations that they have. Again, I mentioned this because I've been in companies where I've seen a junior PM talk product speak towards a CEO, and you can just see them glaze over when they talk about we need to work on problems. They don't care about problems. They've got great ideas that they think they have, and they want them to happen. So just bear this in mind when you try and steer the conversation. Now, this happens in other organizations. Any of you in bigger organizations probably know that not all companies have the kind of product culture that you read about. But the difference here is that you're the only PM, and so you get to practice the product evangelism skills. So as you try and guide people in this direction, I've got to go two words of advice. The first is build trust with them before you try and change too much. Trust is your currency when you try to make these kinds of changes. So build that and don't try and do big things too quickly. And second thing is don't try and change too many things at once. Okay, so that's what things are like when you get in. The second thing I want to talk about is being the only product person. So you need to prepare to be potentially all of these things. Now, you would have seen in the slides that Temi put through before. They have a training on all of these topics. Now, as the only PM, you're probably, you don't want to be doing these things, but there's a reality that you might have to end up doing a lot of these things, okay? So if you land in and there's no designer, you're going to be talking to customers, doing customer interviews, testing any of the designs that come up, making sure you understand whether things are usable because the reality is you need to understand the customer problem and you need to see if what you've built works. Likewise, if you've got no designer, you're going to be doing wire frames for your developers and maybe doing things like design sprints, maybe running those as well. Product Marketer is one that I never really thought I'd ever get close to, but again, if you don't have any marketing people, you need to figure out how you articulate the product, how you talk about the benefits that it has. How do you take it to market? What channels are you going to use? These are all questions that you will end up wrestling with if you don't have anyone else thinking about it. The product analyst, again, even if you get into later stage companies, you're still going to need to do this because most companies don't have a product analyst, but getting data on what's happening is one of the most important things you can do because everything is one of the best ways to help you steer the direction that you're going in. So that might be doing things like setting up product analytics, making sure you're instrumented, thinking about what events you need, you might need to learn SQL so you can avoid bothering the devs all the time to get data every time you need it. There's going to be no BI infrastructure, so you're going to have to make sure that you can self-serve yourself. QA, again, this is one that comes in far too late in many companies, but you're going to be making sure that everything works. If you've got good devs, hopefully they'll be doing plenty of testing and automated testing so you don't get stuck doing regression testing every time you launch something. So advocate for those ones, try and push that away from yourself as much as possible, but you are the last QA always. And then just other stuff that you can't even imagine, like compliance, legal. I worked in a FinTech, so suddenly I was reading through money laundering guidance documents to figure out how we do KYC processes. There's like anything that comes up, you are likely to end up needing to cover. So just be aware that you're going to be going across all of these different things. Now, I don't advocate you trying to do any of these things because you will not be good at them. And even as you practice on them, you're not going to get good at any of them because the reality is you're not going to have enough time to focus on any of them.  You're not going to be a great designer because you're not going to spend the time really developing the craft. But there is light at the end of the tunnel. And that's that if you ever do go anywhere else or your company grows, you will have such a better appreciation for all of these things that it will make working with other people so much easier. So in my current organization, I'm lucky enough to not have to do any of these things. I have either people in my team or other people I can reach out to. But you understand their perspective, you can ask better questions of them. Challenging them when they when they say when they, you know, not challenging them, but probe deeper when when certain things come back and that will make it much easier for you to move forwards. So it's not all bad. And at the same time, it can be quite interesting learning about some of these things. OK, so but prepare to be a jack of all trades and master of none. OK, next thing I'm going to talk about is how these companies are formed because this has some interesting effects. OK, so this is how these companies are formed. So these companies are companies that have got money to go and pursue an idea. They normally people invest in them when they've got an idea. They haven't necessarily it may have done some experimentation, maybe some that maybe they can demonstrate some things that they've done, but they haven't really built a product. The seed stage money that they get is for them to go and build a product to see whether the idea is really worth worth doing. So the way this works is founders somewhere founding team come up with an idea. They go start speaking to Leonardo DiCaprio. He's the Wolf of Wall Street. In this case, an angel version of him who's a bit nicer. So someone that's got lots of money and they go and ask them and say, I've got this great idea. Can you give me some money? You'll see that people that are well connected with people with money find it easier to fundraise. And then once they persuade someone to give them some money, they go and hire a team. They create the A team and boom, you've got your startup. Now, this is interesting because it influences the kind of founders you get. And I like to talk about the founder CEO. I'm going to talk about them because they're an interesting character. You're going to be working very closely with them. And at times, there can be a tension between you and the CEO. Both of you are thinking about the future direction. You're trying to think about what features should be being built. You're talking to your customers. You're trying to learning a lot about the market. The CEO has an opinion on all those things as well. And that can cause attention. I'd also like to talk about it because I've seen lots of PMs talk about their CEO when they've had difficulties there.  These guys are laughing at the front. Maybe they've already seen some of these things happen. But I'd like to try and help gain some insight into why that might be happening. And I want to help you maybe think about how you can learn to love your CEO. Because if you think about your prototypical CEO, it's like Steve Jobs. Now, Steve Jobs was known for having this reality distortion field. If that's not delusional, then maybe I don't know what is. But he was a visionary. But he was also known for being a bit of a last hard times. So I'd like to offer some insight into that. And for that, I'm going to do a thought experiment. So I'd like you to imagine two different CEOs. We have CEO one and CEO two. And I'd like half of you to split the room along here. Imagine half of you are angel investors. So you've got a bunch of cash and you're looking to invest in a hot new startup. And the rest of you guys here are budding PMs who are thinking of taking the smash and joining a startup. And I'd like you to imagine which kind of CEO you would choose. So the first CEO. This CEO wants to change the world for better. They want to make a real ding in the universe, right? They're a serial entrepreneur with a successful exit. They've got the only team that can win in this market. They've hired all the best people. And they've already sold 50,000 pounds of orders. And they haven't even built the product yet. So that's CEO one. And CEO two is more pragmatic. They see an interesting opportunity to help businesses. They've quit their old job to focus full time on this. They've only got 90% chance of succeeding. They're realistic about that they're also succeeding. And they need to raise some money, because they need to finish building their product so they can actually launch and start selling it to customers. So angel investors, who would you vote for? Who would you put your money in? Is it CEO one or CEO two? Oh, we've got a couple of CO2s. And in UPMs, CEO one? Or neither of the companies. The CEO two? Ah, the PM may be more realistic. OK, so yeah. People who voted for one, what was your thinking? Anyone? Yeah, orders here. I think orders is a great one, right? Anyone read Lean Startup? It's called Lean Startup, right? So yeah, any of you guys? People were more going on CO2. What was your thinking there? Sounds a bit more exciting. Sounds more exciting. OK, cool. One challenge. CEO two. Yeah. Then quite realistic. Realistic, OK. Are you selling things from your bills? OK, so yeah, I basically argue that there's a strong selection bias for CEOs that have really strong vision. They can imagine a future that doesn't exist, and they can try and whirl that future into existence. They can convince investors to put money into this venture, even though they've potentially got no track record. They can convince smart people to join their mission, and they can convince customers to pay for something, even though they've got no track record. Can you imagine how that selects the two different kinds of CEO? That's one reason why you get people with that strong vision. So next time you have people, oh, jumped a bit there, didn't I? Oh, it's jumping in my place. Yeah, so next time you're moaning about the CEO being delusional, just remember that they've got very strong vision, and that sometimes when they're telling everyone about the things that they're doing and the things they've done, they can forget about the details about where they actually are. And next time you complain that they are asking you to promise things to customers that don't really exist, just remember that it's close to being lean start-up. I know there's a level which is acceptable, but pre-selling something before you actually develop it is a very sensible thing to do in many situations. OK, so how do you learn to love your CEO? Just remember that they are the best salesperson. They're going to be going out, knocking on the door, trying to get your products sold, and that's going to help them bring in lots of money, from investors and from customers. They're going to be highly motivating for you and your team. The CEO is normally high-energy people, and so try and riff off that. And when you're having trouble sometimes, just try and remember things from their perspective. Just remember that they're responsible for telling investors bad news, and so things aren't going smoothly. They want to avoid doing that, if it's all possible. These are people that they're going to want to go back to and ask for more money, so try and imagine why they don't want to carry that back. And also, if things happen at board meeting, just imagine what's going on there and how that can influence their behavior. And remember that they're responsible for everyone's jobs. So if you start talking about different directions that could impact anyone in the organization, they're the one that's going to have to be talking to someone, not you. You're definitely not the CEO they are. And just try and remember how hard it is. Now, I don't know if any of you have ever read the book The Hard Thing About Hard Things. It just gives a really interesting insight into maybe the kind of stresses that they end up going through. So just try and remember their perspective, and it'll make it much easier to try and suck up what you're dealing with. OK, so I've spoken about CEOs, how companies are formed. The next thing is you kind of go into the company and you get going. The first thing I'd encourage you to do is kind of question everything. Do not assume anything. At the beginning of a startup journey, everything is basically assumption. Now, you've been brought in to do something specific, maybe launch a product, build something out. But just remember that the whole business is a stack of assumptions. And you succeed by creating a successful product, and that's a successful product needs to exist in a successful business. So make sure you get an understanding of where they've really tested things, where things are more uncertain, because anything that comes out in those other areas of the business is going to hit what you do on the product side. So try and get as close to that as possible. Now, again, this is a quote from Ben Horowitz, which kind of articulates that you need to measure yourself in the success of your product, and so the success of the product is the success of the business. So do ask those questions. And I'm going to illustrate this point by just kind of imagining a couple of different scenarios. The first one is you're actually in a large corporation. So you're not in a startup. You're brought in and you're asked to work on the new feature, say WidgetX. Okay, most of the business is actually quite stable.  So you know what to charge for, and you know that it's profitable, and you're launching this new widget.  Things like, do my customers have this new problem that I'm focusing on? We're solving this problem, help the business. Does my solution solve this problem, and can I build this solution? So these are like your classic viability, feasibility, the reliability type questions, but most of the foundations that you're on are quite stable. Okay, you get brought into, you now get brought into launch a new product and a new startup. You know, everyone's really happy because everyone's always got the solution sorted, right? They know what the solution is, and they know what customer problem they're going for. They've been thinking about what channels they have, they know how that's gonna work, and they already know how they're gonna price it. So everything looks good. But as you get in, you start asking questions, like, which customers are exactly what we're focusing on? Like, your vision is like this big, so who are we gonna launch with? You start focusing on some of the customer segments. That instantly starts to maybe shift your value proposition around. You're like, okay, what value proposition do we have? You start asking more questions there, and that starts to ask more questions. So you go, well, if our value proposition isn't quite sure, like what problem are we solving? And if we're not sure about that, then what revenue stream are we gonna charge them again? And like, what's our unfair advantage? Very quickly, you can end up in this situation where you're not really sure about any of these things. I kinda learned this the hard way, working on a B2B2C product. This was a product that was essentially an employee benefit that we sold to companies. They gave that product to their employees. Now I was brought in to work on the bit for the employees. So I come in, working for months away. And in the meantime, we're unable to sell this product to any businesses. And so I was super focused on the consumer bit, which was my job. I hadn't really asked that many questions about the other half of the business, which is where the real customers were, right? Cause these end users were never actually gonna pay for this. It was gonna be the business. In hindsight, I definitely come back and ask a lot more questions about the overall business and be like, how do we know we're gonna do any of these things? Cause actually there was 100% assumption that we'd be able to sell it to businesses based on like one report that they'd read somewhere. It took me a long time to realize that. So yeah, like ask those assumptions, get in there and ask those questions. Cause anything that screws up in the core business is gonna screw up your product. Sorry? Yeah, I should have asked that. I mean, I can't remember what questions I asked when I was coming in, but like it definitely took a long time for me to, what I eventually ended up doing was customer discovery on the business. And at the end of that, I was like, yeah, this is not gonna work. And after that, we then looked to pivot. So yeah, I definitely asked those questions, interview them, grill them on all of the business assumptions. Like what have they actually done? What are they, have they tested anything? Like what kind of proof have they got on those things? Yeah, do that with every business, to be honest. Even the late stage companies I got through recently, during my hiring, I think I ended up getting confidential things that about their, financials, their growth rates, like how sustainable I didn't want to be bent again. Yeah, and the other thing I'd also say that as these things become uncertain, you might find yourself needing to pivot the business in some way.  Is it your problem? Is it like any of these different things? My one word of advice there is if you do end up pivoting, rethink everything. So when you change one thing, you think, right, everything else is stable. If you just change channel, that'll make it easy, right? All you have to do is move from this area to another area. Whenever you change anything, that has big repercussions into everything else you might do. The product, the whole product experience might be different, the whole profitability, that how are you going to think about that could end up changing. And it's, I certainly ended up thinking when you change one thing, you don't need to change anything else, but like I didn't really reimagine all the things you need to change if you do end up doing pivot. So if you do end up pivoting, yeah, try and rethink everything. So you've got a question, yeah. Yeah, just to put it in, if you are pumping up about Microsoft and Google, they're changing their interview technique. What they're doing is they're interviewing themselves before they try and interview in, interview weeks to see if they're asking themselves these questions and if they can answer them themselves before they pose them to sort of sort of see the questions to people. So are they living their values? I don't know anything because I realise I had to pull to their interview and strategy because I realised they're asking questions and sometimes they couldn't even answer themselves. Or their answers were quite lame and this was quite senior people as well. So they kind of, it made them think about where their business was going as well in terms of asking these questions. So I'm just wondering if it was an interview technique that you tried to do. I know I've definitely been guilty of asking questions that are difficult for me to answer. But sometimes that's the point. Yeah, I haven't really ended up. I have definitely thought about the questions and how I judge. So again, this is a lesson, but if you get interviewed by the CEO, they are a good salesperson, they will sell you on the dream. I've seen the CEO sell a bunch of different people in different companies where the company is not so sound underneath. So don't take people's word for it. Like think about what your signals are for certain things. And I think write out those criteria and then do try and grill those during the question. And if you see things that don't look right, then don't just try and think, oh, it'll be okay. Like double down on your due diligence in that area and see if it looks good. I know that my most recent job, whole job process, I did that to the most degree and it's been one of my best moves. So, yeah. Just wondering, in your experience, when you had that conversation with the founder regarding pivoting, because you didn't think it was a sound business. How did that happen? That was really difficult conversation to have. It wasn't really a conversation. It was like a long series of conversations that took a huge amount of time to talk about and change. So when I ended up doing that, the other founder had been causing issues between the founders as well. I think most of the company had kind of come into a similar place. And when I had that conversation, the reason I talk about a lot of those CEO things is that I didn't really appreciate where they were coming from. And you've got to get into their shoes to see their behavior. To me, it was this really clear cut that it wasn't going to work. It was just like, there's no demand here. How are we going to make this happen? If you look at it from their perspective, they're thinking, well, what are we going to sell? Well, I'm going to tell to our investors, your early investors may be closer to you than you think. So I've seen people who have founded companies who have tapped up people that they know in their kind of network. And so you're going to people that in your network and saying, this great idea that I sold you on is not working. So I really didn't appreciate those aspects. And had I known that, I would have probably broken it in a different way. But it is a very, very hard conversation. I also think that what I did wrong when I did that was say, this isn't working. No one wants to know it's not working, right? They want to know what you're going to do about it. I didn't spend enough time thinking, what are the other options and building up those to help explain why we could go another direction. I'm just saying it's not working. It's like, well, so what are we going to do? I had kind of explored some of those things, but I don't think I could have done a much better job and done much more due diligence on those other things. That's what we ended up doing when we finally moved. We ended up having like this big off site and working through a bunch of different options that we could take to see how we could try and move on those. Yeah, but it's not an easy one. When you actually get going, what you're searching for is a viable business and you're running along this line somewhere. And you're going to be doing lots of different things and you're going to be learning lots of different things and trying lots of different things. But it's going to be hard going, right? Because you don't know if you are here at this nirvana where everything's going to work. You don't know if you're, oh, don't know if you're at this point here. Yes, finally, only to find that everything doesn't quite work out as you expected to. You've kind of got this full storm or you're all the way back here and you've got a long way to go. So I guess I've just got one other thing to kind of suggest as you go through this and that's not to try too hard. And what I mean by that is you're going to be putting in a lot of effort, right? And you're going to be putting in lots of effort. But first of all, you want to avoid burning out if you end up taking on lots of things which can feel like it's happening. Second thing is you need to be strategic on what you're doing, right? So there's going to be way too much stuff for you to do. This is a product reality. There's always too much stuff for you to do. That's why we focus so much on prioritization because the list always grows longer and longer. But here you're going to be pulled in every direction. Customer support, you're going to be asked to do stuff there. Things will break operationally and you're the one that just gets involved and tries to sort out the mess. All these things are going to be happening but you need to focus on the high leverage things and think what do I really need to spend my time on to really move the business forwards. Try not to get bogged down in some of these other things if you can avoid it. The second thing is you need to learn about what you're doing. Don't just try things over and over again. So if things aren't working, you need to kind of think about why that's happening. Did you execute it poorly? Is it something fundamentally wrong with that approach? Is it an assumption that you need to learn about? Don't just keep banging your head against the wall trying to hope that it will work out. Learn what you need to do. And then the last one, which is really just knowing when to give up. If you're trying something and trying something and that direction is not really working out, you're getting a signal that whatever you're doing isn't right. And you need to know when you need to change direction. I've got maybe two bits, like two things that you can use to help with this. The first is trying to time box things. So whether you're using something like OKRs or some other kind of planning thing, like set a period of time in which you're going to try and hit a certain goal. If you don't hit it, then it's just a really strong signal that market feedback that that's not the right way to go. And you need to try and change direction. The second thing as you're trying things is think about your core assumptions. So what are your assumptions about the market or the fundamentals still good? Like, is there the market there that you thought there was there? Do you still think that there's an opportunity there? It'll shift around in different places, but does it still look good? Do you think you can solve it? And solve it isn't just technically, it's about your team. Do you have the right team to pursue this opportunity? Especially if you change strategies, right? So if you end up like we did, going from a B2B kind of company where you have salespeople, it's always going to consumers. In the B2B context, some of our founders were super strong. They were really great salespeople. They could sell many things to organizations. We pivoted and went direct to consumer. They become much less helpful in that context. So really, really evaluate, like, is your team the team that you think can succeed? If those same things still look good, then just keep carrying on as long as your money lasts. But review some of those things. Like, your fundamentals good and try and time-box things. The time-boxing thing's really good for helping shift the conversation. When you say, look, we decided to focus on this thing and we're not succeeding, like, which direction do we go on? So that's pretty much... Question. Yep. How do you carve out enough time to be strategic? How do you carve it? I mean, there's the classic things about saying things like, no, right? It's hard. There's different techniques that people have to focus on core things. I've worked with people that hide if they need to focus on something. Like, you know, you can shout out the world is one approach. You can't always do that. Communicate with other people about what the priorities are. There are things. So for example, when I was in my first startup, we were just doing all sorts of different things and I was just like, there are certain things we need to focus on. Things like, there are objective type frameworks that you can use and I think they're useful for as a first layer of kind of prioritization of like, what do we think is the most important thing? That is our objective. Get everyone on the same page. That's the core thing we want to focus on because you might just be in there and everyone is doing something different and going in different directions. That's one way to clear a bunch of stuff. When other things end up breaking, I guess one thing that I ended up doing is always having like the weekly things you need to do. Just maintaining focus. There's like, there's a whole time management type things you can end up working with.  Do you know what I mean?  What you need to focus on is the thing that's really gonna move the needle and then those things will get better in the future. Often your customers, if you're really solving a problem for them, you'll tolerate shitty areas. If you've really got a good product market fit, it doesn't matter if there's lots of rough edges, there's certain things you need to deliver on, those are the things you need to deliver on. Yeah, so focus on those. And then, yeah, so that's really it. So in summary, what I'm saying is you just prepare to be the jack of all trades and the master of none. Make sure you have a great relationship with your CEO, like they are a great asset, just try to avoid it, getting friction for all. Make sure you're building a business and not just a product. Try not to just think about your product in isolation. The product almost is the business when it's in its early stages. So bear that in mind. Question everything. So especially if you end up doing a pivot, like reevaluate everything constantly, update all your assumptions, try and keep track of them. And yeah, last of all, don't try too hard. Don't get burnt out. It's a great roller coaster ride. Enjoy it. Cool, so that's me. Has anyone got any kind of questions at this point? Yep. How do you deal with a CEO that likes to micromanage but in an area where they really don't understand what they're going on about? Yeah, so micromanaging, yeah. It's fine to, it's fine because they've got that vision but sometimes they be a cause and they're like, well, we need this, but then they start to micromanage in areas where they have no expertise but they think they have all the answers. Yeah, so I mean, that is a difficult one, right? I think the first thing to think about is like, why are they micromanaging? So in my experience, people start to micromanage when they don't trust what's going on. So you need to figure out how you can build trust and hopefully after building trust for a while, they will be less likely to micromanage in that area. I think the other thing you can do, especially if it's in the domain that they're not strong at, is just let them do it and screw it up and then try and show another way of doing something. Do you know what I mean? Like if they're gonna really get involved and you can try and let them go away.  And so I think often when, if you wanna take something in a certain direction, you need to let things not go smoothly because it's only by that happening that people reevaluate what they're doing and therefore get their motivation to try and do something differently. Cool, yep, sure. I mean, your advice for someone who wants to join the industry but is already very established in another industry. Okay, so what's the advice for someone who's thinking of coming out of one industry, going into another industry, going into product management, not just in any kind of context? Same. Yep. That we can't quite see it and I'm like, I don't understand why I can tailor to explain it because it's like, there's transferable skills quite hard to explain it. Yeah. That first role is always difficult, right? And I think if you're changing industries and companies, that's always difficult. I think narrowing the amount of change to one thing can help. So for example, if you're already in an industry, stay in the industry, but try and change role within that industry because that way you've got a lot of domain knowledge. Like that is one area of being a PM is building up domain knowledge in whatever thing you're doing. If you've already got domain knowledge, it'll be much easier to move into PM role within that same domain. So don't try and change industries and company sizes and roles all at the same time. Maybe try and narrow it down just to one. So if you're in a company, I don't know what kind of size company you're in, but trying to move in the company is the best way. That's how I ended up getting into product. I started by being in one kind of role and working quite closely with the product people. And that's how I built up some relationships that they were happy to take you on as being junior. My current company, that's how we're bringing our junior PMs end up coming in. They've got strong domain knowledge in one area and we need junior PMs. And so they can transfer that way. I've seen that happen quite a lot. So hopefully you can do it in your company. If you don't think you can do it in your current company, try and join a company with your current role where you think that opportunity could end up arising. Obviously that can be difficult because interviewing saying, I'm coming for this job, but what I really want to do is not do this job and do something else. But some companies in certain areas are more likely to have PM roles. So you can go somewhere where there's a lot of product management going on. And then I think once you build trust with that organization, most organizations are quite encouraging to try and help people move around. Do you have any advice for getting the CEO to... You spoke about the project management view of a product manager. Do you have any advice for getting the CEO to acknowledge what a product manager is or how...? Yeah, so I almost like... Try and make them think it's a good idea. So your question was basically, how do you get the CEO to see what product management is about, essentially? So just pick elements of product that you think you can move in. Don't try and show them the whole thing. So if they're quite road map-driven, feature-driven, you can go great. There's different aspects of this, right? So they might be asking for too many things. There's some arguments you can make around why you might want to deliver things iteratively. You can get it into your customers' hands faster. They want it to get it sooner. Doing two things at once, the same amount of people, is going to be slower than doing... Well, not slower, but it's going to take time next. If you do one at a time, even if they're not interlinked in any way, you should halve the time for the first one to get there. So position it in terms of things that they will care about. So speed of delivery might be one of those things. In terms of if they're very fixed on a feature set, understand why... One of the most powerful tools you can have is asking questions about things, because the more questions you ask, the more they might start to question about why they're doing something. Just think about how you do this. I remember my CEO got quite upset with me at one point because he felt like he was being interrogated, because I kept asking more questions. So do it in a kind of... Try and think about how you can do that in a positive way and not making it a...  Why do you want to do this? This is a great idea. How did you come up with the idea like let's let's explore it because I need to understand it so we can deliver it and try and unwind their solution into the problem? And once you get there, you can then start to be like, okay, that's great. Like, this is a problem. Like, how do we know this is... You know, you can start to go, how do we know it's a problem? Can you do some testing? Gather more evidence to help you steer things. Yeah, sure. Do you have a follow-up question? So I've got the company to buy in on the whole product, so I didn't buy using the roadmap, actually. But it's a start-up, and it's quickly growing and quickly changing. How do you recommend best to maintain that roadmap to manage its maintenance? So the question is really, in a changing company, how do you maintain and set expectations on the roadmap?   Like, I guess it's something happening. It's something happening that makes me think that you're worried about it or like... I'm worried, it's just, it changes a lot. Yeah. For starters, I try and keep the next quarter pretty much cemented, but then stuff after that changes and things, when they have a shareholder meeting and then that changes. So that sounds good to me. Yeah. Yeah, okay. It's just, how do I manage the expectation better or what's there and make sure? Sometimes it does get looked at. It's like a project management tool, almost, and I'm trying to avoid that completely. So one thing that some people advocate is like, sticking, don't want to do it, but like, kind of problem-type things on there. So don't say it's the delivery of this thing. Say like, this is the problem. So like, our customers are having this problem. We think there's a big opportunity in it. Like, don't define the solution. Yeah, focus it more on the kind of problems you want to focus on. If you, I don't know how you're thinking about measuring things, but you know, talking about successes or things, because the thing is, people don't really want delivery of stuff. They want their outcomes, right? They want to make, your CEO cares about making money and the current customers. Like, if you can shift the conversation onto those things, then you can still meet the expectations around we're trying to move these things, whilst the things underneath are shifting. So that might be something else you can do. But it sounds like it's actually in a better place if you are able to change it. And as long as they understand why those things are changing, then I think that might not be, you sound like you're not in a bad place. It's just like. Not bad. It's just worrying sometimes. Yeah. I wish my house next two weeks or so. I don't know if it's four or something. I think it's in a better place, but... Cool. Why don't you like working in problems? Why do I like working in problems? You said you didn't like putting problems on the road? Just because when you try to sell that to someone that doesn't know much about product, then we're just like, what do you mean? Like, it's so hard for them to grasp that if you kind of say, we need to focus on problems, they're just like, seeing the glaze happen to some people. So, yeah, like, it's what you want to be doing, but reposition it in some way so that it doesn't sound, yeah. So, the value is a bit straightforward. Focusing on value. What value is it going to bring? Yep. It's often that they've actually said something to someone else, and that's what's driving them to say, you need to do this thing. Like, I promised the investors that we were going to do this thing.  Like, just, yeah, like, the more you can understand it from their perspective, I think it's easier to understand the motivation. How do you deal with promises that have been made, that have been made when you're not there to potential customers? To potential customers. Yeah. Or maybe even if you're in the room and you can't necessarily, like, just say no. Yeah, so, it depends on your time frames, right? So, sometimes they don't remember all the details on those things. I think the other thing to think about is to not break the promise, but like stagger the delivery of stuff, for example. So, you can say, it's not that we're not going to deliver this thing, but like, what's the most important things to you? Like, you can come back in the follow-up conversation to talk about those things and be like, well, you said these things are the most important. So, we're just not going to focus on this thing that we promised you here. And as you continue that conversation, if it's just a random promise for one customer and you're really focusing on the common problems, hopefully you'll be picking other stuff that they might care about anyway. So, you can kind of move on the table. I'm not quite sure of the context, but it might be more B2B related if they're making those kinds of things, yeah. So, that can happen. If it's really important, then you might have to think about, you know, especially when you've not got many customers, is this something we're going to have to do to, to, you do think it's going to break this relationship? That might be something you do end up needing to do. In fact, it's absolutely essential. So, if something's going to hit, you can't just sort of, you know, accept it when it doesn't go down. Yeah, there's a lot of sleepy shouldering. That's required. That's true. That's true in every org, I think. Yeah. Well, they can be more open in some places, yeah. Sure. Does it shift the business point of view, or do you actually see them as two separate things? No, I think it's a huge, huge shift in business point of view. So, take away startups. Think about most companies. Most of your companies are probably not that kind of agile on the way they think about delivering stuff. Most companies probably still, not most, but a lot of companies still think about project delivery. And I think it's a change in mindset to thinking about how do we deliver, or we talk about value, about how do we deliver value in chunks and not have, like, these unrealistic expectations about how certain we are about things in the future. So, yeah, so I'm just trying to get back to your question, which was exactly was, I don't know. Yeah. Yeah, so do we see, do I say kind of project and product management as two different things? The companies, I think, with a more project management mindset, are almost always output-focused, whereas I think if you can move it more to outcome-focused, you get away from projects, because very quickly you start in a direction and realize the project you're working on should be something different. And if you don't have the ability to change that, then you're not being as outcome-focused. And actually, that's largely driven by, like, management often, who like to be able to review all of the ideas and go, yeah, this is one that we bless, and therefore this should happen. This is one that shouldn't happen. What they should really be doing is betting on the things they want to happen, and then letting other people figure them out. And, yeah, if you're talking projects a lot, I find that generally it's because they're output-focused. Yeah, you do get to see that at times. I think it's because they're still trying to manage projects from the top, right? So there, people have heard, like, Agile waterfall, because of this concept, right? Everyone will laugh, right? So, yeah, so, like, I think often you end up, yeah, with the project managers being Scrum Masters, like, the places I've seen them in most Agile don't have that kind of role, really. You can be a project manager, Scrum Master, like, my current company has an Agile coach who's the equivalent of the Scrum Master, who's not in a team, who's not delivering anything, just comes to the ceremonies for the team. So there's a product owner, no real Scrum Master, just a coach, I'd say. And, yeah, they're not really involved in any of the core initiative type things we're doing. Any other questions? Yeah. Have you dealt with a situation without a clear engineering manager? Without a clear engineering manager. What kind, doing, so the question is, have we dealt with a situation without a clear engineering manager? Yeah. And the engineering manager, is there something you're looking for them to do? There is no clear engineering manager. Just a bunch of different developers that you're working with in team. I've worked in somewhere, maybe there's a, what kind of problem are you encountering? So I mean, it's kind of hard to negotiate on how things get built or how they, if you think about trying to deliver things fast and get the value out as soon as possible, you'll have a team of this four developers to each of them kind of, they do work together, but, again, there's no clear engineering direction. So a lot of the time, a lot of stuff won't come up until it actually really, really needs doing it, or you just set you back. So there's no overview of what's going on with engineering, because there's no really to go or negotiate with properly. Okay. So it's not like, okay, so it's like the tech leadership aspect, really one thing. Okay. So I guess there's a couple of things you might, you could end up thinking about. Is there anyone that's more respected in that group of people? Can you essentially find the person with the most influence and use them as the routine? That's one possible angle. The other one I can think of is they do report to someone, right? Who do they report to, the CEO? Yes. You can talk to them about some of those things. Potentially. Yeah. Try and get them involved with that. Yeah. Are you doing retrospectives or anything like that? Yeah, you are. Okay. And so the things are coming up in there, but they're not, because what I've found is sometimes is when you're just the only kind of product-focused person is that there's a much stronger gravity around all of the dev things and things that we bleed into design, other areas like that can be much harder to get people on board. You need to find your advocates for those things. So I was lucky that in my startup where we only had developers and we had none of these other roles, we ended up getting one of the developers to do the marketing. Who had done some copywriting once upon a time. And we had a front-end devs, if you can get them, I think, depending on what you're doing, but they're normally much more customer-orientated. Not always, but they often are. And they can end up being an advocate. So again, when I was in a company with no designer, they were not like the UX level, but they were kind of more UI in the UI area. But definitely much more customer-oriented. So find someone who you can bend their ear and use that to try and persuade other people, maybe.