okay well uh welcome to cross checks this is kind of a fun experiment for me I wanted to see um from the uh ux and and design Community who would be interested in this topic um and I think it's really interesting because a lot of people get into product management from user experience but it's not always a an intentional decision so I wanted to talk a little bit about what product management is how I found myself in it what you can expect from it um and why I think it's cool but uh maybe you leave hear and you say this isn't for me at all and that's fine too it's going to be more of a sort of introduction to what product management is it's a discipline and not so much around best practices once you're sort of a acting product manager so welcome it's been a while since I've gone to an isda event I go probably two or three a year um just kind of randomly and usually when we're ramping up to a startup weekend but who here feels like they have a good grasp on product management already cool yeah I feel like even people that are in product management are kind of like I don't really know what I'm doing but um uh you get better with it so I'm glad uh I can be sort of an icebreaker for you guys my name is Jay um Jay Claus I'm a product manager here at Cross checks um and I'm just kind of generally involved in the community here I went to Ohio State I'm a buckeye um I studied Journal ISM before eventually switching into Marketing in the business college and I mentioned that because I actually think journalism is a huge reason why I've been sort of well suited for product management and I'll get into that a little bit later um I also am an organizer and facilitator for startup weekend startup weekend is a global organization it's a 54-hour event where we bring people in over the course of a weekend they come they have the opportunity to pitch startup ideas that they have um they form teams around those ideas and over the course of the weekend they build a prototype present that prototype and business to a set of Judges McKenzie's been a judge for us before um and it's really a an educational experience for people to learn about entrepreneurship we bring in Engineers designers any other background marketing law teaching it's it's pretty great um and I've been doing that for about four years now so thank uh startup weekend for the food they sponsor tonight uh our next event is in May and it's going to be at the idea Foundry which is great because I just finished the second floor and it's actually going to be a themed event around maker so we'll have things there for you guys to make physical prototypes and it'll be it'll be pretty dope one last plug for organizations I'm involved in I'm on the crate Columbus commission and the crate Columbus commission exists to empower young professionals to engage with their City uh we have a grants program every year that Andy is a big part of of um LED last year and we recognize outstanding young professionals so if you know someone in the community that's representing uh really great values and doing great things as a young professional we would love for you to let us know about them because quarterly we recognize really strong young Professionals in the in the city um and have them recognize that city council so if you Google create Columbus commission you'll find it but the website is create Columbus with a period between the B and the US uh it's it's very clever so that is the final plug uh before I came to cross checks I was uh one of the co-founders of a ticketing uh ticketing platform called tickers it was a lot like StubHub on one end you could come and buy tickets from the secondary Market on the back end we basically bought tickets up front from you in terms of site Credit so it's kind of like a site gift card so you could quickly uh liquidate your tickets and buy new ones we sold that company to a company in Florida in 2015 worked there for about a year that was my unofficial introduction to project management uh product management just because it was by necessity we never had more than four people on our team so anything that needed to get done that was not legal and accounting was sort of on my plate to do and um even design so it's nice to be in an organization now at Cross checks where no one lets me touch Photoshop anymore um so here I am I've been at Cross checks for nine months I'm a product manager if you don't know what we do uh our mission is to build an identity layer for healthcare so people can connect and share information about their health it's on the wall back there what that means is we have products for hospitals independent Physicians and even patients to better own their Healthcare identity and share that with their providers so cross check has been around since about 2013 on that mission and it's cool to be a part of that so for me as a product manager I oversee three products our Hospital product our product for independent Physicians and our patient mobile app so that's what I do here that's why I feel like I am suited to speak to you tonight I hope you agree um and so what I want to talk about is what is it like being a product manager and the way that I would best describe that is this wonderful gift which will just Loop and loop and loop this is from Spider-Man 2 but I'd actually like to take some guesses as to why you think I'm showing this gift as a product management tool if anyone's brave enough yeah you protect the team from SC that's actually true true I should sometimes I'm the one who enacts the scope creep as John can tell you uh but yeah I should protect the team from that anybody else want to give some ideas yeah you're forward being different true yes that is almost exactly what I I would say um I like this because he's holding out like this and I literally feel sometimes that I am holding on to like trying to hold together the needs of a lot of people right like in one hand you've got the business needs in one hand you've got your engineering team that you want to represent um behind me the train is sort of like sort of like the the release that's coming and I'm just trying to like protect it and keep everyone together and I'm not trying to stop it I actually want it to go faster but um I think this is actually a really good representation of what I feel like on a day-to-day basis so I think of a product manager a little bit as the glue between a cross functional team bringing a product to Market there's a lot of different people that you represent and work with on your team as a product manager and I think one of the best definitions of these different roles and responsibilities I've read is in Marty kagan's book inspired how to create products people love so I'm just going to go with his definitions for the most part here in this next piece to explain what some of these different terms are because you hear product manager you hear project manager you hear product owner you hear all kinds of stuff so let's lay a baseline for what I'm getting into tonight and then I'll get into it a little bit more so we'll start with the product manager there are a couple of key responsibilities as Marty defines it um assessing product opportunities and defining the product to be built are the main components um once an opportunity is discovered uh and the company has decided to be well suited to pursue that opportunity it's the product manager's job job to Define how that product is built and what it looks like that can include the features and functionality the user experience in conjunction with the user experience uh uh person um as well as release criteria so I'll get a little more granular in that later since that's the focus of the talk but other roles the user experienc designer as you guys are well aware of I'm sure um developing an understanding of the target user creating the tasks navigation and Flow that is both usable and valuable to the user as Kagan puts it um so the heart of this is software should be usable meaning users can figure out how to use it and valuable meaning users actually want to use it for for their job so that's a big important piece project manager is a little bit different um main responsibility here as Kagan defines it is the project scheduling and tracking so actually going down ticket by ticket with the engineering team map mapping out the road map um the key things that need to be completed and on what time frame this is what is also referred to most frequently as a product owner or if you're into agile a scrum master um and depending on the organizational size and culture this may all fall under the product manager a lot of the time Engineers they do the hard work right right John yes they they say okay I hear your responsibilities and I can make that actually exist which is great um they also are responsible for a lot of testing and validation on the product so without the engineers the train doesn't go um product marketing I know some of the individuals here are in product marketing as well key responsibilities here telling the world about the product managing the external launch of the product providing tools for the sales team they go sell the product um sometimes and I would not rec recommend this but in some organizations this is also assumed by the product manager um really depends on the size of the company like if you're talking 2014 when I was with tickers and we had four people yeah I did this too but when you have a large organization it really doesn't make sense for this role to be owned by the product manager some some ratios that Marty Kagan thinks are good for a software team one product manager per every five to 10 Engineers I think that's pretty good too in my experience 10 is getting a little heavy and a little difficult um but also one ux to every one to two products managers I read a pretty good piece on first round capitals blog by uh the lead designer at Airbnb and he actually recommends sort of a one to one to one ratio with uh design which I think is also great I think the more uh user experienced designers you have in the room the better but um he says one to two potentially so in my experience um product managers and user experience have lived on the product team that's the way it operates here at Cross checks we have sort of a product division that is the product managers our head of product and uh the user experience designers we have acted the product managers also as project managers or product owners as it's defined sometimes uh we do not directly manage people and I think that's important and I'll talk to that a little bit later why that is um but really what it gets down to is as a product manager you want to work cross functionally with your team and it's healthier and more productive and better for the users frankly if you have some sort of healthy discourse with other functions of your team and you can't be a boss you have to be a leader um and you have to sort of almost negotiate and explain clearly why the things that you are laying out in the requirements are necessary for the user and you need the rest of the team the engineers the ux to feel like they are open to give honest feedback and criticism on that um like I was just saying product engineering marketing and sales are separate divisions that work sort of at this unilaterally with uh the product manager so I'll talk a little bit now about the process that um product managers go through and sort of people who just are involved with the product generally you hear a lot about this sort of build measure learn cycle right um this is kind of the traditional model I I don't disagree with this but the way that it is always stated build measure learn I think does not put enough emphasis on the front end of learning before you build and measure so I would almost just like turn this uh what's a corner of a triangle 60 deges 60 Dees uh and say learn build measure repeat and so at Cross checks here and in my experience this is our process first we do problem discovery going out to the market understanding what Pro what problems exist in your target market um and talking to a lot of users to make sure that is an actual problem that comes from a lot of customer interviews going out talking to people leading nonbiased interviews so that they give you honest responses you can kind of connect the dots between their responses in that way once you found that Discovery um user validation and I should have user validation of your solution if you have found what you believe be a problem and you think you have found a solution you should do some form of user validation that the solution is wanted and something that is valuable to those users and asking them like hey I have this idea XYZ would you buy this and them saying yes is not leading a very good and unbiased survey and those results are not really valid frankly um as I'm sure Mackenzie can tell you um surveying is a really valuable skill and doing validation right is incredible inedibly valuable and unfortunately pretty rare I found so after some validation that's where the product manager really comes in and starts doing one of the main focuses of his or her job which is writing a product requirements document basically laying out what it is that is required for this product to do and how this the solution should function like I was saying earlier kind of defining those features and functionalities to actually work um and then that comes with a conversation with the rest of your team with the engineers with ux to say here is the problem here is my proposed solution here is what I'm laying out as requirements to meet the user's needs let's have kind of a talk and what comes through that process is um a really good feedback from other people who are not as close to the problem and can kind of look at it with fresh eyes but also you'll find that especially the engineers in the room are really good at finding holes in logic and in functionality and figuring out okay okay what's the best way to go about this what are some of the pitfalls if we go about it a certain way and how do we best approach this um the designers will have a lot of questions around okay let me make sure I understand the user their needs how this should look look and feel so that the next part of the phase they can begin doing some of the wireframing and mockups and I put these as sort of the same step but two components meaning uh there should still be a lot of conversation around the wireframing component because once the the ux feels that they know how this should work look and feel for the user they need to get some feedback from the engineers to say that won't necessarily work because of these components or here's another way that I would recommend it so that we don't have to take on an extra two weeks of Dev time to do it the way it's mocked up here um and then building an actual full-fledged mockup to look like the software so you can hand off that set of work to the front engineers and they can build a kickass product after everyone in the room sort of agrees on the solution to where it's going we form a technical design document between usually a front-end and backend engineer it's sort of a contract between the two of them to say this is what I'm expecting from your side and this is what I'm planning for on my side usually the front end saying I need I need these these endpoints and I expect them to be implemented this way because here are how the components are going to work um and writing that down is just so important because even if you have a great meeting and a great conversation about how you're going to implement this if you don't write it down during that meeting you may misremember it and you can go build two separately disconnected components based on two different assumptions and lose days weeks of Dev time um if you don't have something to refer back to as sort of a contract so once that technical design document is completed and approved NE to the fun part my favorite part is building it um hand it off to the engineering team team who take it and run with it uh based on that design document build it to the specs and um you know you'll get feedback all along the way there's a lot of conversation between the product manager and the engineering team during this build phase because as in-depth as you go in the product requirements discussion or mockups or technical design document inevitably there will be things that come up while building that you say well I didn't think about this Edge case or this circumstance or this actually wasn't implemented the way I thought how should we approach this um and so there's a lot of Rapid decision- making as a product manager you're giving you're given a little bit of information and asked what what direction should we go with this and sometimes I can go to uh one of the lead Engineers on the product maybe that comes to you but uh you need to make that decision quickly and you need to make that decision with good judgment so you can move forward and doesn't in uh sort of impair future development either after that's built um and been sort of tested by the engineers who are building it we get into test mode we take that to a team that we call Quality Discovery and they go and really bang on it as a user from all use cases we have a set of regression tests that we run to say right now all of these components work in production production meaning out in the world the product that is actually touching people's hands these functions all work does it still work after we built this new stuff uh and it's super super important especially at a level of scale because if you have hundreds thousands millions of people touching your product and you don't do proper testing and some component is tweaked God forbid it's like the login screen you will instantly know about it once it goes into production um and it is not fun and it can be expensive it can be uh costly in terms of brand Equity with people it's very important to test things thoroughly and anything you can do in terms of Automation in your codebase to test that is even more ideal it's sort of a a dream state in a lot of places but uh automation is very nice for testing finally everything passes testing you go through multiple environments usually in testing we have a development environment which is uh the sloppiest of the environments but once it feels good there you move it into QA which is I believe quality assurance I never really ask what QA stands for um but it's the it's the second environment to test things in if things look good there you move it into Stage all of these are just test zones it's not touching real users uh nobody actually sees it outside of your company once it goes into stage stage most like most looks like production and if it works in stage in theory it should work in production um when that's not the case you find out immediately and you have a bad day at work but um most of the time it's a good test so once that's all tested and given the go ahead by quality Discovery or whoever is doing your your testing you can move to release that out to the public and so like I was saying on the previous process slide I look at this as the first two steps are sort of the learn phases you're doing problem Discovery and user Dev validation then you have quite a bit of build phases um going all the way from the product requirements document down to the test phase I'm not sure why I didn't do a better job of stretching that um followed by your measure phase which comes basically after you release once you release you should have put on some sort of analytics you should have some sort of hypothesis around how this will perform what the impact is to users how they they will use it and once it's in the out in uh production and out in the world you can start to test those hypotheses so that goes right back as soon as you start measur measuring you start learning and then you can start building again forever so where do product managers come from I don't really know um it's not there's two there's two reason reasons uh there's not a lot of formal training in terms of software product management it's kind of a new discipline and it's not really something that is offered at a college level that I am aware of I'm sure there are some uh sort of vocational courses you can go through I'm sure there are online courses uh the world of online education is amazing but a lot of the people that I know got into it sort of by accident and just discovered that they loved it um a lot of times s is someone that's just been given a shot somebody that was already in the organization they're saying man we are trying to get this stuff to move out faster we need to improve our processes we need some want to own the launch of this product you seem like you have a good handle on it can you go out and do it um and they just kind of live there and run there and the reason that I mentioned journalism earlier is I think that's actually the reason that I am uniquely uniquely qualified to do product management because what journalism taught me very early was a very strict adherence and respect for deadlines and also very strong written and verbal communication which is very important when you're communicating with lots of different disciplines within your team so um and so the other problem here is it's a little hard to measure what a successful product manager looks like uh being sort of the go-between between a lot of processes a product manager can look really good because of his team he can look really bad because because of his team metrics on how to measure that or you can look at velocity of releases but that's not necessarily a great thing you can look at NPS scores saying we put this product out we interviewed our customers how well it's going in theory the product manager should be the one that defin the solution good for the products or for the the users um they should rate them well there's there's some ways you can do that but it's it's a little difficult so one Trend that I'm tracking is recently there's been sort of a question around product management because in Valley especially it's a harder skill set to come by right now the uh the demand is out stri Supply so I wouldn't say this is a strange headline way to put it but it's basically just coming down to right now there's a relative lack of product management talent for demand the way that we saw the same sort of trend for software Engineers for the last you know 20 years so um what does that mean for somebody that wants to get into project man product management means higher Sal so here some day at the same article pull out um with some pretty high popping numbers for those of you who are management but average product management salary in 2016 for the US $138,000 it's pretty crazy obviously it's viewed by some of the coasts I'm sure but um there's there's something to be gain here in this world so at the end of the PMs can come from ler places they can come from Engineers people who have been uh in the building and put out great products who think they want to get more involved in the process of it want to get more involved helping to lead people they can make great product managers people want use your experience or your interface design they can make great product managers they understand the user or fight for the user they will um really help make it look and feel the way the user wants people W customer service they're as close to the user as anybody else maybe they feel like they are really a champion maybe they feel that they can really step up and communicate well because their experien in customer service people in marketing people who know the market they are already leading processes leading teams people in sales um and even users themselves sometimes you go out and you have a user that's highly highly engaged and they say I love your product here things that I recommend doing better uh seems like kind of a longer path to get into it a little more while uh really we come just not any it's more about personality and skill set to get into it so what makes a good product manager in terms of personality and skill sets uh here are some skills that I think really lead to somebody being well positioned to be a product manager time management is incredibly incredibly important so if you're the individual who's always late to the party or the show or whatever engagement um product management may not be for you it's you got to really run on time you're expected to hit deadlines you're expected to report on things at certain times and to that end creating a sense of UR is super super important um obviously there are some pitfalls of if you're trying to rush things too quickly you can get one of those situations where you have something go out to the market that's premature but in general you are responsible for helping people move at their most efficient and effective speed and you have to create that sense of urgency communication is something I beat the in the ground a little bit but a lot of what you do is in writing whether it's in a product Department whether it's by by email whether it's in slack you are going to be communicating so frequently and the more you can do to be clear in your initial Communications you're vo back and forth is really going to help because that's just another part of time management more clear you are the more quicker you adding to those skills being excellent at Framing and planning and that is to say when you talk to your team and you do planning exercises to say here is our next Sprint Sprint being being a sort of a one or two we body of work that you and your engineering team are about to take on you need to be really good at framing why that work is important and what it means for the company and even framing your expectations you know this is our Sprint we need it to be completed by this time because of X Y or z uh you have to be really good at communicating that to your team because like I said earlier product managers are not bosses you don't usually lead directly people you need to lead and not sort of tell and being able to frame that is going to help your team move more quickly and with a sense of purpose you need to be analytical and objective in the way you think and a lot of times um that's sort of hard to do it's easy to fall into bias but your job is to take in all the information that you can whatever is available which isn't always a lot and it's almost never complete but you need to look at that objectively and say this is what I'm going to take from this information and here is why and apply that to your decision- making which falls into the next Point having good judgment in that decision making you're almost never going to have complete information and the slower you act uh the worse off you are so of course you want to make informed and wise decisions and not be too quick to act and too impulsive but there is definitely a balance of moving quickly even if it's for even if it's deemed later to be the wrong decision there's a lot to be lost by indecision um and then a b a little bit of a business acumen because a lot of times you are communicating the business needs to your engineering team or you need to understand how the product actually impacts the company and uh that comes down to a little bit of understanding how uh the business works and operates there's a lot on the line When You're Building Products could be it could be that your deadline means an entire contract which could be any amount of money um and you have to understand that General traits and attitudes in uh for a product manager you have to be passionate about product uh your own product certainly but even other products a lot of the times I'm just downloading certain mobile apps that are in the space or I hear pretty cool or I'm going to the store and test driving a Tesla just because I love seeing new stuff and I love trying to sort of reverse engineer how that stuff works and that's just something that you have to inherently have because you're going to be living and breathing the product every day and if you don't care about it then you're going to get burned out really really quickly customer empathy is something and a reason why sometimes people and customer service um and sales come into product management you need to really fight on behalf of the user a lot of the time because sometimes in those meetings where you're talking about why you should be building something to a certain requirement you're going to be asked to go about it a different way because maybe it's easier to engineer but if that easier path makes the product less useful and valuable to the end User it's not a better way to do it so you need to really understand that user put yourself in their shoes and understand what they would want or your product isn't really going to isn't really going to cut it there is a level of intelligence that you need to do and really that flows into a lot of the skills it's um you know it's it's something that you can't really teach um you can't teach intelligence but if you don't have it um it likely leads to failure in other areas you need to be pretty Relentless and have a strong work ethic um because it's a it's a certainly a full-time job if not more than a full-time job while while the team is building you're writing new product requirement documents for the upcoming uh initiatives like your job never stops there's never a done build measure learn is shown as a circle for a reason and you have to be ready to go to work and go to battle every day and part of the reason I wrote emotional intelligence next is you can't freak out um because the job doesn't stop and you need to be on your game and lead people and move quickly and there's just no time for a lot of emotional faltering and you need to be on top of yourself and keep your self honest when that is happening so you can get it in check and continue to lead and just be a leader um and to that to that point confidence is super important too because to get people to follow you and say okay I believe that you understand the user and I think those requirements make sense you need to have some sort of confidence in leadership ability so couple of suggestions in clothing closing couple suggestions in clothing check out this from J crew um couple suggestions in in closing and then we'll get to some questions um you need to become organizationally bilingual between business and engineering and this is something that I hadn't really articulated until recently but another reason I've been well suited for product management is because since I had led a business before and I understand the motivations from that top level down I'm able to communicate that well with my engineering team and because I can kind of understand logic from an engineering perspective I can understand time constraints and I can Lobby on the behalf of my engineering team for timelines and certain things that are uh plausible and not plausible and rational and not rational and you have to be kind of that go between because a lot of times maybe the business team is speaking English and the engineering team is speaking Spanish and you got to be the Spang English so it's great to be able to be complet completely fluent in both but I've gotten really good at speaking Spang English uh you need to become task and timeline oriented if you want to get into this world everything comes down to Priority everything comes down to priority you have to prioritize certain tasks of your own you have to be able to manage your own time you have to manage the time of others you have to understand how to weave timelines between deliverables and you have to break that down into tasks that people can take on whether it's yourself your engineering team the marketing team the sales team uh and you need to really respect timelines too actually the best way I can put this is a lot of the times you're going to be past the ball let's say and that is just saying we have this information we need you to make a decision or we have gotten here and you need to give us X Y or Z so that we can move on otherwise we're blocked and a good product manager gets the ball out of their Court as quickly as possible you should get yourself out of the way of being the bottleneck as frequently as possible because that is one thing you absolutely can control and you should do that uh get used to Notifications my phone just has a lot of red circles with a lot of white numbers in them all the time whether it's emails whether it's slack whether it's anything else you're going to get a lot of notifications from people who need your help support um decision making and you got to get used to it and you got to respond to them because it's part of getting the ball out of your court could be 8:00 at night could be 6 o'clock in the morning and your customer service is waking up with uh somebody in a different time zone you got to help them out and then back to a point I made earlier you have to become comfortable and skilled at conducting customer interviews because you really do need to be that customer Advocate you need to be someone that understands them well and to understand them well you need to ask good questions that are unbiased and get valid good information there is absolutely no replacement for talking to and listening to your users and I know you guys as user experience designers appreciate and understand that as well so really there is absolutely no replacement for doing that get out there talk to as many people as you can and finally here's just a a suite of tools that I use that I would recommend if you're interested in product management or if you just want to be more productive and task oriented yourself in the job that you already have uh I use Evernote for note taking it's great because it's beautiful it's simple it syncs between your computer and your phone instantly it's it's super easy obviously the Google Suite most people use that already Gmail Google Drive Google Docs Google Calendar Trello is what I use for personal traff task ma personal task management I have a board that divides things up into engineering design sales I have a column for today I mark them with certain colors so I can quickly see what tasks I need to get done and in what order and I can knock them down move them to the done column and I have this giant done column that validates me when I go home at night um slack for team communication I think most people are aware of this at this point it is really par like Second To None when we were using when we were doing tickers we were using Google Google Hangouts and Skype at times and it was miserable just thinking now what I would do in an organization this size without slack blows my mind I have no idea how how we've come this far um jira is what we use for our engineering task management this outlines specific tasks for our Engineers um with discrete descriptions of what you require to complete the task it's really good for tracking that through the environments through the different process of building and testing Lucid chart is what we use in the product team for outlining processes and workflows so we can quickly get feedback on whether that process makes sense and is logical and then that is something that we use to sort of dovetail into wireframing which I personally use balsamic for a lot of you guys probably have much more skill than I do and can just pen and paper or use sketch or something of the sort but balsamic has a lot of pre-made things like phone outlines you can put on there and and laptop monitors and login buttons you can basically wireframe an entire interface in balsamic by just dragging and dropping things Invision is really really good for working with the sales team to show full mockups and demos of a product you can take and I'm I'm preaching the choir here I know but you can take um full uh full Graphics put them into this interface annotate certain areas so if you click an a login button you can move to a screen that shows the login screen and it really looks like Frank and wear it looks like a product that's really working and Uber conference is what I use for conference calls it's free it's uh easy to sign up you can send people a link the usually the waiting music is a little more pleasant than anything else I've used that is it so thank you uh here is my email address if you guys want to get connected I've been shamelessly plugging my Twitter in the lefthand corner of this deck the entire time um I write from time to time and I think I'm going to start writing more on product management so if you want to learn more you can join my newsletter um which is just at J claus.com but I'd be happy to answer any questions if you guys have them please [Applause] clap cool anybody have questions I'll come sit down I have tried and failed to teach myself to code a lot of times um and it just become comes from there's this really good graph I saw once that was talking about like the valley of sadness of teaching yourself how to code because there's a lot of really great softwares to get you like minimally minimal fluent and then so you're like feeling really great about how you're doing and then there's not a lot of software or not a lot of courses that teach you like how to think for yourself and build things you kind have to muddle through that until you feel proficient on your own they start feeling great again I never got out of that first Peak or at least out of the beginning of the valley um and what I also found for me um if I were to be able to code I would be able to go and maybe spin up some of my own ideas and that'd be awesome but it's not the skill set that I am best at in an organization and so do you focus time on learning that skill and then decreasing Your Capacity to do things like this or do you focus on what you do well and for me it just wasn't worth not focusing on what I do well so a lot of that from engine so so you need speak Spanish and also Spanish because there's a lot of manager doesn't know allu these I think a lot of times honestly I think that I can speak engineering pretty well but it actually does come down to that the engineers speak product better than I think and they're just like like yeah we know what you're you're saying and we're not going to demean you for saying the wrong things um which is valuable on its own right and that at least means that you have the respect of the team but um it really does come down you need Engineers that have that knowledge too just wondering your experience how much aomy do you have decisions people com to you for to get these questions answered can you the authority to them the answer do your exper it it depends on the size of the organization because if it is the four person four person organization that I ran before like yeah all the autonomy in the world uh here we have a head of product some questions I need to escalate to him because I know they have larger impacts and it's a larger decision it kind of becomes just a gut feel a lot of the time um I I feel like I have a lot of autonomy I'm sure that changes as you become a organization um but it depends a lot on trust depends who your boss in it's very situational so a lot of the times I think product managers have a lot of autonomy but if you know that it has cross team dependencies or implications it's probably a larger conversation uh the way the organization is here I have to do that I think in some organizations the operational structure is sometimes Engineers feel like they have to answer to you but it's really not the case so in in any case even if you do have that Authority and you're not leading it's just like any other role in any other organization it's not going to give the best results um but a lot of a lot of what I've read and learn on product management is it's very important that you do not have that total absolute authority over how things are built that's where a lot of the timelines come in um because it's not it's not healthy or wise for business to dictate the timelines usually or at least they cannot dictate the timelines and body of work because they don't have all the information made or available to usually make that decision well so they need to either have a timeline or they need to have a body of work and you as the product manager need to give them the other half of that equation a lot of the times and that comes from kind of being that bridge because if they try to hand down both like all the gets shoveled downhill and you usually have a gut reaction like that is just not at all possible and you tell that your team and they say that is not at all possible and it only makes your capacity worse because everyone feels defeated from day one um and I think that's an unfortunate Truth for a lot of organizations that that tries to happen just because you know you think you know something but you really don't some things are more complicated just from technical perspectives that you wouldn't imagine like some things may be arranged a certain way in an interface and you would think oh those things play nicely together and if we add this on top it'll work well but what you don't realize is you have to go about some other imple implementation so you don't blow up another part of the application it's it's it's hard so really you need to be transparent with that part of the organization with what is either practical on a timeline or what timeline is practicable practical for a deliverable and you need to stick to that then you're going to be held beholden to that decision once it's made um and that's probably one of the measures of success you can hold product managers to is just being good at those timeline and um sort of work estimations could you ask that one more time I'm sorry oh sure so actually I'll tell this by kind of explaining a story when I came to cross checks I actually came in a role that was uh was called strateg IC growth which was just like a fun little title but what it what it amounted to is they wanted me to go out and validate ideas at the market um and it was almost a sales Ro as business development role and so what I had was I was basically given an assumption and given a market they said we want to get into this market and we have an assumption about how we may do that we need you to go talk and figure out if that assumption is correct and if not uh what should we do to enter this market and bring back that recommend a so for the first month that I was here I was in my car visiting 20 Physician Offices a day trying to just talk to any physician I could or any office manager that I could and it was a lot of conversations and it was a lot of starting the way I start a lot of conversations with with customers is walk me through your workflow because I may have an assumption on what their workflow looks like but it may look different between users and so for like a an office manager at a doctor's practice they will say oh well patient comes up signs this clipboard I call their name they come up uh I validate their driver's license I put it into this software system and if once I understand the workflow I can better understand my assumptions around how our solution may fit that workflow and kind of speak to that but what is most valuable and what is a most valid response is if somebody propose somebody volunteers a problem they're having and especially if they're already searching for a solution then you're like really close to getting them on board so you need to ask really good questions to discover what it is that they are frustrated with and hopefully one of the things they mention is what your solution provides and if you start to see a trend like that between users and you're in a really good spot and so a lot of times I'll start with walk me through your workflow then I'll talk about okay with that workflow if you could wave a magic wand and take care of three aspects or make three things better what would those be um and just see what they come up with sometimes I even start I don't even talk about the workflow I just say like what are the top three problems in your life and if work is one of them that's good and if it's run to things that you're hypothesizing that's even better but you need to really ask non-leading questions like that um and try to get them to volunteer what their problems are um and maybe they'll have some ideas around what it could look like too and that could be great information for you but um anytime you kind of plant a seed in their head you've already kind of slayed the experiment yes absolutely um it should be a living document but um I mean John can answer this better than I could but um it's good to call out when changes are made and a change along at the bottom or something Google Docs tracks that automatically but this should be a living document until whatever that tdd let's say it's like the first version of something or a very discreet deliverable once that's finished if you add to that project or product later you should not use that same document yeah it's it's absolutely responsible for the or it's a it's a responsibility for the product manager um and the other thing about validation that's interesting is it shouldn't just come up front like when you get through the exercise of wireframing and doing mockups you should do some gut checks with users there also before you start to build sometimes timelines are hard and it's really tempting to not get that feedback um but I I I basically write down a set of assumptions so the first month I was going out there I had a set of five assumptions that I thought may be a need for customers and every conversation I went to I either wanted them to volunteer it or I wanted to ask a question that got them thinking about it so that I could kind of rate what their interest level was on it and this came down to me making a Google a Google form and after every visit I would type in address of the of the of the uh practice name of the person I talked to notes on that visit and then I had a ranking scale sort of a matrix of the five hypotheses on a scale of 1 to five how much it seemed valuable to them um and I just go in my car and filled out my phone between trips and the rest I would put into Salesforce later but um I think that's one way to do it it really depends processes are a pretty fun thing and everyone kind of likes crafting processes in this world that was that was a good way to do it it wasn't maximally efficient since I was putting stuff back into Salesforce afterwards but you have to come up with a hypothesis you have to go and then get them to speak on the topic so you can hopefully glean some information about your hypothesis and how they feel about it and and make a rating I mean it's it's going to come down to you kind of making a gut feel I guess you could ask them specifically one through five how do you feel about this but um I feel like that's difficult to do tactfully too that's probably a better question for Mackenzie she could answer that better frankly I wish we did it better but I think what I would do if I had and it's not to say I don't have the control over this I should just push harder for it what what we do is we we'll meet weekly and talk about things and that's good but um I wish that we talked more in terms of problems encountered uh assumptions made that were proved right or wrong we don't get into the depths of that frequently enough and I think we could and it could just be fairly anecdotally um it could be tracking it throughout the week as an individual and bringing it to that meeting um we do have a slack channel for the product team that we talk about some of that stuff but um I think because we UND because we are tasked with speaking to users and building the product if we if we get things wrong it is most beneficial to speak about that and be honest about that with your team and it is also very difficult to do because you're basically openly saying I was wrong which some people may either internally feel or externally project that you're doing your job poorly and so sometimes you don't have that transparency like you should I think it's really important that you do yeah and science SCI cometh a are fix your things learn actually or should a little bit I mean what happened was basically a I was I was feeling like this is starting to feel like a sales role but I'm so glad that it happened in that way because I think at the time I understood our users as well as anybody else in the company in a very short time of being here um and essentially because of my background and because we went to the market and we had validated a concept and the company determined they wanted to go after and build that now we had basically created a role for a product manager to build that they said who better than someone with experience and knows the user we have we have a marketing Division and really I think it's more product marketing than anything else um because a lot of our sales is B2B we have a patient facing mobile app but um for the longest time we had B2B sales and so most of that is product marketing and I worked very closely with them for a long time um we recently we changed our model a little bit and changed our strategy a little bit um they are a separate division in my role currently um I'm basic Ally servicing products that already exist that we're maintaining for a current customer base so it's less recently but for a long time I worked with them quite a bit because you wanted to send either it was what I found was that I was qualified to help craft the messaging of the product and help hand that off to the marketing team so they could make good materials for the sales team and that was where my insight came from the most because I understood the user and I understood what types of words um and types of needs would speak to them so they could make it great do their word smithing do their design do their their planning and campaigning and run for the sales team I don't know the waterfall type of organization well enough to answer that I don't think I really since since this all came for me out of experience it's all come like I actually learned product management probably from the engineers that I first worked with at tixer it's like here's the way that we work and I adapted to it and that was agile um I wouldn't say it's been that drastic more so what we found was you can validate a product and a market and people may want it but if you don't have a strong enough distribution or sales uh strategy and it doesn't have Network effects it can be really difficult to get that product to take hold at a scale that makes sense so that doesn't make the product or hypothesis invalid but it does make it difficult to continue certain strategies with that product and so um we've like I mentioned and alluded to a little bit earlier we've changed what our primary focus is right now and so the product that I had began building is just out there being serviced for current customers um but we're not actively approaching the market because it it we had to throw bodies at it yeah and that doesn't didn't scale well enough what when we stop doing a product when I stop owning a product uh it depends I think we have a few enough products that need to live and continue to improve that once you're once you're managing it you're just kind of there until you move on to a different product and that's less of about metrics or processes and more about focus and resource allocation um because because any any product you're going to put out there especially in a software world you're going to want to continue to iterate on and improve and so someone's going to have to be managing that into perpetuity whether it's you or somebody else it's it's not really very practical to think that you're going to put something out there it sticks and you just let it go and don't worry about improving it because there's always going to be bugs there's always going to be changes in support with browsers or operating systems there's always going to be things to support and upkeep um so I don't think it's a matter of metrics so much as priorities for the business and resource allocation are you asking that specific because I'm worried about like three right now we're we're juggling three but what we have is a discrete resource allocation meaning an engineering team a product guy a portion of a ux guy and our team is responsible for upkeeping these three products now granted it all comes down to Priority we only have so many people that can can build and improve so we may be spending the majority of our time and resources on one of those three products and letting the other two sit until critical bugs arise or some support needs come up um but that just then comes down to a matter of priority for your team if these are the products you're responsible for and uh you have metrics or time lines or deliverables to put in for any one of them you have to prioritize that build um the that road map effectively hope that answers your question this is changed and gone through a few iterations with us but basically every discipline is its own Division and those divisions are then divided up into a resource allocation at some point in time for an usually undefined period of time but they say this is a re resource allocation now J your team has nine Engineers to work with um or this group of six engineers and this group of three Engineers who are going to roll off at this period of time um it's nice it's nice when you know what that period of time is but it's usually a pretty discreet group of people um so that you can have some accountability and responsibility around things but that's totally fluid and can change pretty rapidly depending on needs and priorities of the business as a whole weeks monss yeah it really it really really depends um because you may think it's going to be quarters but then hits the fan and you got to change or maybe something else is just going really really well and you're like we got to pour gasoline on that fire and you pull people to help do that um it can change pretty quickly especially at a company this young or at this size we have sort of the agility to do that or maybe the naiv um and uh so yeah it can change pretty rapidly there's no promises well anybody can raise that conversation um the product head is no different to the head of engineering than the product manager is to the engineer um he can't the product head can't make that decision it really comes down to depending on your organization structured if everyone reports up to the COO it's going to be his call if it's up to the CEO it's usually it's usually Sean he's usually our CEO at this point but if there is a need it's usually something that you bring up at a fairly regular meeting across functions and say this is happening here's my evidence I think we should go in this direction and then it's just a and usually a decision by Sean always I mean that's kind of what that that was the Spider-Man gift um yeah it's really hard and I I I give this analogy a lot of times it's like um you know how when you open up your iPhone and you see your batteries going down really quick and you double click and you see you have like 30 apps running I feel like becoming a product manager is all about increasing the number of apps you can have running in your brain and not winding down your battery as quickly and so I'm trying to like constantly increase that capacity without losing my mind but um I drink a lot uh do I meditate I have begun meditating I've tried and failed before and now I think I'm getting a better hang of it what I find to be more effective at least right now um working out has always been kind of my meditation um the other thing that I do that I find to be super effective when I hold myself to it is something a college professor taught me called morning pages and that is either if you're going to do it handr handwritten which I don't usually do um it's usually three pages or I usually type an Evernote and I hold myself to a thousand words what I find is a lot of times when I feel prized and I'm not moving quickly it's because I have some inner monologue that I'm not even processing and so if I just sit down and write and write and write and write it's out and I can like process it as it's passing through me and then it's gone then I can focus on things and usually I kind of as I'm writing it out I start to prioritize and break things down and that's super helpful but yeah I when I was a when I was a kid I could memorize things and had like endless capacity for reading and paying attention and memorizing things and I can't my attention span is so short now um and I don't think that's for the better but a very newom perspective so kind of ear on how I oneid a lot ofs team having has that your experience I think the way you're referring to product owner there is how most people would refer to product manager I think our difference is purely semantics here and that's like that's kind of what I would get to honestly when it comes down to a lot of these methodologies it's like okay this guy wrote a book and it sold a million copies and it's a best seller and this is how you refer to them but when it comes down to your organization like usually the roles are pretty aligned with what someone writes about but nominally it changes whether it's because somebody was incorrect to First time or had a different opinion but um you know what I've read about most is all three of these terms project manager product owner scrum Master are usually kind of lumped into someone that's responsible for tasking and timelines aot totally agree I think those are two discrete roles no matter what you call them whether you call the scrum Master a scrum master and the product manager a product owner either way I totally see what you're saying and the product manager or whatever that role is has to represent the users um there's also like something legitimate to be said about the size of the organization sometimes it makes a lot of sense to have separate product managers and project managers and sometimes like in my case here I just do both and that's more of necessity than necessarily um opinion or desire a lot of times until it's not a necessity then that's the way it is cool off the hook oh nope let's get let's get Grim line here you need to have a pretty open and transparent conversation with engineering and this is another reason why that relationship has to be super healthy because I don't know everything John knows and John has a much better expectation and understanding what that timeline's going to be and he could just light me he could tell me that's going to take three weeks when it's going to take two and I and I wouldn't know so you need to you need to speak to your engineering team you need to know who to trust or you need to know at what level of trust you can have with somebody um and really the best way when when I feel like I'm at my best is when I'm saying when I'm getting there buying and saying what what is the timeline we can do this on and getting them to agree to something sort of audacious because now they're not being told they feel like they're invested because it was their response that's like one I feel like my team is operating at its best but um you know it's it's it can be hard because you don't know off the top of your head and you got to go to someone that knows that answer better and ultimately you're sort of beholden to It For Better or For Worse yeah that that meant that the timeline was too aggressive um and that can mean one of two things maybe you misestimated it and everyone is just like we we did that wrong it could also be that the timeline and the body of work came from the top or somebody didn't have the full information that they should have and they're still just expecting that it's done by that time and that's the most unfortunate situation because everyone feels like they've been slighted and it's not fair