Build

Just when you thought you had a handle on your job... it’s time to lead a team! Time to be responsible for others. Their career growth, emotional well-being at work, and job satisfaction.   You’re excited by the new opportunity and want to grow into this role, but it feels like you are starting from scratch. You felt highly competent in your last role. Now it feels like there is a steep learning curve ahead of you, and you may or may not have mentors or role models to help.   If you’re already in a leadership role, maybe you chose it or were promoted into it based on previous performance. But you may or may not have a lot of experience leading a team through a number of contexts such as tight deadlines, conflict situations, peacetime, and re-orgs!   As a result, in the first few months of your transition, you might have struggled to feel like you’re making progress. Overrun by meetings and constant context switching has left you feeling unaccomplished at the end of your workday. You wonder if you're using your time wisely.   You might be left asking yourself, “Am I doing this right?” And, “Should I go back to being an individual contributor?”   I’m here to tell you that all these doubts are normal.   It might not seem normal because no one took the time to map out what a day in the life of a leader would look like. Or maybe they did but only shared the glamorous parts ;)   Well, it’s normal to have doubts, and it does get better!   In this month’s Build episode, we’re going to tackle the topic of being a first-time leader, and to help us out I’ve invited Lara Hogan, who is a coach and trainer for managers and leaders in tech. She is currently the Co-Founder of Wherewithall a consulting and advising company dedicated to helping tech startups and non-profits grow and execute with ease. She was previously, a VP of Engineering at Kickstarter and a Director of Engineering at Etsy.   Lara has a new book coming out called Resilient Management, and in the Build episode, she’ll be sharing insights from it.     Here are the highlights with approximate timestamps: @5:00: Why Lara chose to focus on helping new leaders and managers hone two skills: human growth and resiliency @7:30: How every team (old and new) goes through four stages of development: forming, storming, norming, and performing, and what you as a leader can do in each stage to support your teammates @10:00: The six core needs we all need at work, and why even missing one might have caused you to feel emotions like unappreciated, distant or detached, or underwhelmed @14:40: Why Lara no longer suggests using a README to help your teammates get to know you, and what to do instead, especially when it comes to setting expectations @16:30: Know what you are optimizing for—instead of fixating on a management style or philosophy @18:00: How to spot areas of friction and handle them! @20:00: Why many first-time leaders default to mentoring (aka advice giving) and need to switch to coaching (guide teammates to discovering solutions) @24:20: Do highly functional teams even exist? @24:45: How to handle delivering bad news because as leaders that is one of the things we often have to do Want a copy of Lara’s new book Resilient Management? Leave a review for Build on iTunes, then hit reply to this email to let me know you left a review, and I’ll share an e-book copy of Lara’s book with you! (Limited to the first 5 people who respond.)   Here are some additional resources Lara mentions in the episode for you to check out:   Core Needs: BICEPS by Paloma Medina Four Stage of Group Development by Bruce Tuckman -- Build is produced by Femgineer (http://femgineer.com/).

We’re living in an era where there is more than one path to gaining freedom and flexibility, though often it takes some trial and error to achieve it. Gregg Goldner is an example of someone who was tired of missing out on important life events and wanted more freedom and flexibility in his career. In the last episode of Build, Gregg shared his journey going from being a school teacher to a software developer. He chose to be a freelance software developer because he valued honing his craft. This choice meant he’d had to find work and clients who valued his talents. If you’ve haven’t had a chance to check out the episode yet, you can watch it here or listen to it here. Another approach to gaining more freedom and flexibility is to be your own boss and start your own company. In the beginning, you may choose to do most of the work yourself, but there will come a point in time when you will need to hire someone because you’ve hit the limits of your expertise, or how much work you can realistically do. While hiring help may seem like a panacea it comes with its own set of challenges. Add in limited time and budget to find a quality hire, and the challenges grow. I’ll admit that it’s taken me more than a decade to find people I enjoy working with, can rely on, and learn from. I won’t claim that I know how to hire the perfect people every time—frankly, they don’t exist. What I've learned over the years is how to come up with the key criteria needed to source talented individuals, suss them out, and help them grow over time. I've tested and tweaked the strategies when hiring people in startups and growth stage companies. In today's Build, I'll be sharing these strategies with you. The episode is taken from a live online group coaching call I hosted last year with first-time founders who were hiring technical talent, but the strategies also apply to hiring managers who are looking to fill non-technical roles. Even if you aren’t the person making a hiring decision, it’s a valuable episode to learn how you may be evaluated in the future! As you watch the episode today, you’ll learn the following: The pre-work you need to do before you start recruiting How to source candidates through your network as well as online and offline channels How to evaluate a candidate's work history, projects, and references How to vet people who are reliable, can communicate clearly, and will produce high- quality work The difference between vetting a freelancer and a firm—as well as how to avoid the ‘gotcha’ moments! Want more help recruiting, onboarding, and retaining talent? Check out our previous episodes on what to expect from new software engineering hires, how to onboard new software engineers quickly, and how to keep newly hired software engineers motivated. If you're looking to hire product managers, you'll find the following episodes on hiring product managers, interviewing them, and training and retaining them helpful. Finally, if you’re looking for UX designers, tune in to our episode on sourcing, vetting, hiring and working with UX designers. -- Build is produced by Femgineer (http://femgineer.com/).

When I was in my early 20s and someone told me to prioritize freedom and flexibility, I’d cringe and think, “Yes but how?”   Over the past fifteen years, I’ve asked this question to people I’ve met. Through trial and error, I’ve learned to incorporate or tweak parts of their how to fit my needs. As a result, I’ve learned there is more than one how, and to be wary of those who claim there is only one!   One approach we explored earlier this year was building a Company of One. Paul Jarvis and I explored how he went from being a freelancer and providing a service to scaling his business to create products. In the Build episode, we shared some of the common themes. If you missed the episode, you can check it out here.   This month, I want to rewind and explore the first part, becoming a freelancer.   Becoming a freelancer is one approach to gaining more freedom and flexibility. And while it’s easy to glamorize being your own boss, it can take time (many years) to get a business off the ground.   You have to figure out how to market yourself, manage clients, price your service, and still have enough hours left in the day to do the work!   All of these tasks can leave you feeling overwhelmed. To help you think about the transition, gain some perspective, and most importantly, work through the overwhelm, I’ve invited Gregg Goldner, who is a freelance developer and President of Two Sun Traders, LLC to share his experience.   Whether you are a freelancer, want to be one, or are just curious, I’d highly recommend tuning into this week’s episode to learn the following from Gregg:   Why Gregg wanted more flexibility in his life and chose to transition from being a music teacher to a software developer How he made the transition to becoming a software developer The skills he learned from having been a school teacher and how they applied to software The experience that led Gregg to choose to be freelancer instead of a startup founder How he initially priced himself, then changed his pricing over time The importance of honing your craft How he interviews clients and picks projects   I loved this quote from Gregg because it showcases how you need to focus as a freelancer:   “Putting on every single hat and then realizing I don’t like half those hats. Wouldn’t it be great if I didn’t have to do those things? What are my strengths and weaknesses, and how can I find people who have different strengths and weaknesses?” — Gregg Goldner, President of Two Sun Traders, LLC   In the episode, Gregg mentions a number of resources, here are links to them:   The Mythical Man-Month, Anniversary Edition: Essays On Software Engineering by Frederick P. Brooks Jr. Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin Refactoring: Improving the Design of Existing Code by Martin Fowler Code Complete by Steve McConnell iOS Development Tutorials by Ray Wenderlich A weekly video series on Swift programming A hands-on guide to learning Swift Subscription learning platforms Packt and Lynda.com   If you’ve been following Build for a while, you may recall I did an episode with Jessica Hische who is a letter, illustrator, and type designer a few years ago on a similar topic: How To Prepare To Strike Out On Your Own And Pursue Your Creative Calling. Listen to the episode here. I always find it helpful to revisit a topic and compare notes, plus some people’s voice resonates more than others, so I’d highly recommend you check out that episode too! -- Build is produced by Femgineer. 

I am the self-appointed family travel agent. Though if you ask my partner and the rest of my family members they’d agree that I am the best person for the job.   Why?   Because over the years I have become adept at making sure I don’t overlook the details when planning a vacation—you know where the devil hides! And who wants the devil to turn up on their vacation?!   Unless of course, it’s a blue devil ;) #marchmadness #goduke   I take the time to read through ALL the descriptions and fine print, talk to customer support agents to find out if there are any additional fees, and make sure that family members who have accessibility needs like my 10-month-old baby and 82-year-old grandma will be taken care of.   Once I’ve done all this planning, I know I have truly earned my vacation ;)   Despite all my effort, there have been times when things didn’t turn out as planned. Like the time I booked a home in India only to find out that the address was incorrect. The host mixed the street name with the city name. We would have had to drive 3 hours after 24+ hours of travel, but I called customer support and they resolved the issue for us quickly.   It was a positive customer support experience: responsive, seamless, and efficient. As a result, I continued using that service to book my travel, knowing that if something screwy happened I could count on them next time.   But there are other companies whose customer support agents place me on hold—for more than a few minutes. When the agent returns, they tell me that I’ve reached the wrong department. Then they transfer me to the “correct” department. Once the transfer is complete, I have to repeat what I told the first support person to the second support person, all the while hoping that they can help me resolve the issue. They can’t. When I look at how much time I’ve spent, and the exorbitant fee or unreconcilable charge, I am frustrated and vow to never do business with them again!   I know I’m not alone.   No one likes being at the receiving end of a bad customer support experience. It’s easy to place blame on customer support, but it’s not their fault because the problem originated somewhere else—when the product or service’s feature was being created.   Someone designed the experience in a way that wasn’t particularly customer friendly, and then it became a challenge to change the experience because of the silos that formed in the company between teams: sales, marketing, product, engineering, and customer support.   At the start of a company, teams are usually flat and highly collaborative, but over time, silos start to form, slowing things down, making it hard to innovate, and distancing teams from their customers.   Is it even possible to slow or stop them from forming? And to enable everyone across teams a chance to interact with customers?   Well in today’s episode of Build we’re going to answer these questions and more, We’ll show how silos form of overtime, some best practices for keeping silos at bay, and what to do once they have formed to break them down.   To help us out I’ve invited Nichole Elizabeth DeMeré who is a B2B SaaS Consultant with 20+ years of experience in online marketing, and a champion for customer success.   As you tune into today’s episode you’ll learn the following from Nichole Elizabeth:   Why everyone on a team including software developers and engineers should have a chance to interact with customers, not just people who are on the customer support, sales, and marketing teams How to empower teams to break down silos, and a framework for evaluating experiments and features that factor in constraints When to automate and when to interact with customers How silos form over time, how to avoid them, and what to do once they’ve formed Why when building B2B products it’s important to focus on making your customers successful not happy Why you need to rethink off-boarding customers and make it easy for them to leave   “When everyone on the team is aware of the voice of the customer, everyone is super excited about what is going on (with the product).   If you really want to stand out right now it isn’t pricing, it’s team alignment and customer experience.” — Nichole Elizabeth DeMeré   In the episode, Nichole Elizabeth mentions a number of resources, here are links to them:   Net promoter score (NPS) How Transparency In SaaS Offboarding Reduces Churn by Shayla Price Customer obsession course with Lara Weaver SaaS Growth Playbook with Trevor Hatfield Appcues Segment.io Wootric -- Build is produced by Femgineer (http://femgineer.com/).

We began this month exploring the theme of career transitions. In the first Build episode for this month, we talked about why even if we want to transition in our careers, we don’t and get stuck in a role. If you missed the last episode of Build you can check it out here. If you were wondering how to get unstuck, then today’s episode is for you! We’re continuing our conversation with Amy Sun who is a partner at Sequoia Capital, a venture capital firm. Amy began her career as a product manager, transitioned to a product manager and most recently became a venture capitalist. Having gone through a number of transitions herself, she’s learned to navigate them in a number of contexts. Even if you aren’t going through a transition yourself, it’s a valuable episode to tune into, because as a teammate, hiring manager, or leader you may find yourself working with someone who is going through it, and you’ll be equipped to help them out! As you tune into today’s episode you’ll learn: How to avoid being typecast into a role and be your own advocate How to figure out what companies are looking for within a role How long it can really take to go through a transition and how to keep your motivation up Why short trial periods can be helpful, and how to set expectations and criteria for grading performance How to get feedback and build awareness to improve How to transition between companies versus across roles within a company How to fill in skills gaps, build trust with peers, and present to leaders “The opportunity won’t just present itself one today. Believe that you want it. And then tell people you want it. Sometimes you’ll get push back. Even if you do, you have to continue to fight for it, if you believe that’s the path that you want to go down.” — Amy Sun, Partner at Sequoia Capital __   Build is produced by Femgineer (http://femgineer.com/).

Career transitions are tough for all of us. Leveling-up or transitioning into a new role or field is challenging because we have to prove that we can do the job, especially when our resume doesn’t reflect relevant or exact experience recruiters or hiring managers are looking for.   The countless rejections may cause us to want to stay in our current role and hope that someone will acknowledge our skills, talents, and efforts.   However, we cannot build a career on hope alone!   In today’s episode of Build, we’re going to share what holds people back from advocating for themselves successfully, and in the next episode, we’ll dig into ways you can make the transition happen.   To help us out, I’ve invited Amy Sun who is a partner at Sequoia Capital, a venture capital firm. In case you’re curious, Amy’s firm Sequoia Capital has been investing in companies since 1972. They have invested in 250+ companies, and some notable ones are Apple, Google, Oracle, PayPal, Stripe, YouTube, Instagram, Yahoo! and WhatsApp.   Last year at Grace Hopper, Sequoia Capital was the sponsor for a workshop I was co-teaching with Karen Catlin, which gave me the opportunity to meet Amy. After the workshop, Amy and I had the chance to chat, and I learned about her exciting background and thought it would be wonderful to share it with you.   What surprised me was that Amy didn’t start her career with the intention of becoming a venture capitalist; her first real job was as a snowboarding instructor!   After graduating from college, she began her career in tech as a product marketer, then eventually became a growth marketer and product manager.   As you tune into today’s episode, here’s what you’ll learn from Amy:   How to deal with the inner critic inside each of us who worries about: “What people are going to think” and get your foot in the door in spite of it How to suss out if you are missing experience How to handle roles that are and aren’t clearly defined or vary between companies The value of shadowing people and doing your homework How happenstance and luck play into transitions   “If you think about your career as the sum of all the knowledge you have—it’s not like you’re throwing away all the experience you’ve had in the past to start from scratch. Having a diverse set makes you more uniquely qualified for certain roles. So rather than holding yourself back by thinking: ‘Oh I don’t want to start from the ground (zero), and all my experience before is useless,’ think about it as compounding upon each other.” — Amy Sun, Partner at Sequoia Capital -- Build is produced by Femgineer (http://femgineer.com/).

In the last episode of Build, Sarah Doody, who is a UX designer and entrepreneur, and I debunked many myths and misconceptions around UX (user experience) design, as well as the benefits to having a UX designer on your product team. In today’s episode, we’re going to switch gears and talk about what UX designers can do to stand out, and then share how companies can go about sourcing, vetting, and hiring a UX designer. Finally, we'll talk about how they can work with software engineers and product managers. I always learn a ton from Sarah, and I found this episode to be really insightful because aside from being a UX design herself, Sarah has reviewed the portfolios of 700+ UX designers!  So whether you are a UX designer yourself, or looking to work with one, I’d consider this a must watch Build episode. Here’s what you’ll learn from Sarah: How to find and reach out to UX designers 3 Things UX Designers can do to stand out What UX designers can do if a past project hasn’t yet launched or there was no clear result How software engineers and product managers can work effectively with a UX designer How UX designers can avoid being overwhelmed by projects that aren’t related to the product Here are links to the resources Sarah mentioned in the show and some additional resources to check out: Design Value Index https://www.dmi.org/page/DesignValue/The-Value-of-Design-.htm Slack / Facebook Groups Related To UX Designer Hangout: https://www.designerhangout.co/ With Candles (for junior designers): withcandles.slack.com User Defenders: https://community.userdefenders.com/ UX Careers Tribe: http://www.facebook.com/groups/uxportfoliotribe (this is my group) Design X: https://designx.community/slack/ Mixed Methods: https://www.mixed-methods.org/community1/ UX Career Resources From Sarah UX Portfolio Formula (use code BUILDSHOW for 50% off): http://bit.ly/2t05Ztu Free UX Portfolio Blueprint: http://bit.ly/2t04yvp UX Careers & Job Interview Playlist: https://www.youtube.com/watch?v=H2_D298hAH0&list=PL73Nci5CBE-7OFGFhYawlJh9bYZd-a-b1 -- Build is produced by Femgineer (http://femgineer.com/). -- Femgineer's Confident Communicator Course 2019 is coming up! To learn more visit: https://femgineer.com/confident-communicator-course/

Happy February! It’s a brand new month, which means new Build episodes. If you’re new to Build or maybe missed episodes here and there, know that I’ve previously covered a number of topics related to design like design sprints, product debt, product redesign, accessibility, being a freelance designer, creative confidence, the rise of the design executive office, designing with empathy, and the art vs science of ux design. It turns out all those episodes weren’t enough, and there’s still a lot to cover! So this month we’re going back to the theme of design, and start by covering why it’s important to work with a user experience (UX) designer. Given the significant shift to designing user-friendly interfaces, it might feel like I am preaching to the choir. However, some companies still struggle to justify the work of a UX designer. Plus, given how young the field is, it’s continually evolving, and people are always writing in and requesting I cover design :) People still aren’t sure how a UX designer adds value, how to go about hiring and vetting them, and how they can work with software engineers and product managers effectively. Just like how software engineering has become more specialized over the years, design has faced a similar change. However, people still grapple to understand the nuances between a graphic, visual, and UX designer. In today’s episode, we’ll dive into the different types of designers out there. Then talk about some of the myths around user experience design. In next week’s episode, we’ll talk about what UX designers can do to stand out, how companies can go about hiring and vetting them, and how they can work effectively with software engineers and product managers. To help us out, I’ve invited Sarah Doody who is a UX designer and entrepreneur (formerly based in NYC). You’ll learn the following from Sarah: Benefits of having a UX designer on your team from the beginning How to think of user research as an investment How to co-design and how it helps handle pushback and the handoff period How design-minded companies outperformed S&P 500 for ten years Here are links to the resources Sarah mentioned in the show and some additional resources to check out: Design Value Index https://www.dmi.org/page/DesignValue/The-Value-of-Design-.htm Slack / Facebook Groups Related To UX Designer Hangout: https://www.designerhangout.co/ With Candles (for junior designers): withcandles.slack.com User Defenders: https://community.userdefenders.com/ UX Careers Tribe: http://www.facebook.com/groups/uxportfoliotribe (this is my group) Design X: https://designx.community/slack/ Mixed Methods: https://www.mixed-methods.org/community1/ UX Career Resources From Sarah UX Portfolio Formula (use code BUILDSHOW for 50% off): http://bit.ly/2t05Ztu Free UX Portfolio Blueprint: http://bit.ly/2t04yvp UX Careers & Job Interview Playlist: https://www.youtube.com/watch?v=H2_D298hAH0&list=PL73Nci5CBE-7OFGFhYawlJh9bYZd-a-b1 -- Build is produced by Femgineer (http://femgineer.com/). -- Femgineer's Confident Communicator Course 2019 is coming up! To learn more visit: https://femgineer.com/confident-communicator-course/

Do you ever feel like you’re caught between making personal concessions and compromises in order to advance professionally?   I felt this way less than six months ago.   I was getting ready to transition from maternity leave back to work. Part of my transition plan was to initially work part-time so that I’d have time to rest and take care of my little one. Running my own business would give me the freedom and flexibility I needed to do this.   However, during my maternity leave, I became overly concerned with providing for my little one. As I transitioned back to work, I decided I need to think about taking on more clients.   A dear friend of mine had advised me to create a document with non-negotiables so that I wouldn’t be tempted to make concessions and compromises for things I needed from a client.   But I was concerned about how clients would perceive my non-negotiables.   In today’s episode of Build, I’m going to share how I went through this transition last year.   Once you’ve listened the episode, I’d like to know what was the last career transition that was spurred by a life event for you? How did you manage to pull through without compromising on what you needed? Feel free to tweet your response to @poornima. -- Build is brought to you by Femgineer (http://femgineer.com/). --  Femgineer's Confident Communicator Course 2019 is coming up! To learn more visit: https://femgineer.com/confident-communicator-course/ --  Enjoyed this episode and want to support the show? To become a patron of the show visit: https://www.patreon.com/build -- ## Easy to Set Non-Negotiables But Hard To Stick To Them Transcript   Career transitions are tough. Especially when they are spurred by life events.   They can feel endless, overwhelming, and cause us to shortchange ourselves by making concessions and compromises on what we need.   In today’s Build episode I’m going to share a recent transition I went through and how I managed to get through.   So stay tuned!   Welcome to Build. The show that debunks a number of myths and misconceptions related to building products, companies and your career in tech.   I’m your host Poornima Vijayashanker.   I had previously mentioned that I’d be experimenting with the format of Build, so today’s show is a solo show with just me.   I’m curious to hear your take on it. As always, feel free to leave a comment below. I don’t always have time to respond but I’m always listening, reading, and learning from audience members like you ;)   Last year, in the midst of my maternity leave I started to worry, more so than I usually do, and specifically about money.   I had previously written some blog posts about how I had gone through a round of interviews at companies, and ultimately decided that running my own business was going to provide me the most flexibility and freedom.   Somehow all the logic had seeped out of my postpartum brain and been replaced with a need to provide for my newly born child.   Despite being a good saver, and being a part of a dual income household, staring at my medical bill for the delivery made me worry about all the unexpected expenses that would start creeping up.   I’m a strong believer that I tight budget isn’t enough. You also have to make money.   So I thought about all the things I could do. I could answer all the emails that were piling up from recruiters or I could start working on the course I wanted to offer in the fall.   But this was 6 weeks into my maternity leave, I was having a really hard time summoning the energy to do something new.   Not to mention having the time to do it.   I’d need time and energy to either prepare for interviews or market a new course. Plus I’d have to persuade others that I was credible.   I re-read my own advice, and realized I needed to find a way to cash in on credibility that I had already built up without compromising on my non-negotiables.   That meant instead of proving myself to someone new, I needed to go back to working with people who knew I was credible.   I called up a client that I had worked for back in 2014 and 2015 to see if they needed help. They did and they didn’t need it until I was done with my maternity leave. So the timing was on my side.   There were just two catches: I need to commute up to SF and they had reduced their contractor rates.   Both of these directly conflicted with 2 of my non-negotiables, which were working commuting only two days a week and my rate.   I decided I wasn’t going to budge on how I priced myself, and told my client to check if there was more budget.   I reminded my client that I was reliable, and they remembered the quality of work that I had done.   I was also fortunate to have others vouch for me.   I put the ball in my client’s court and waited patiently for their response.   My client came back and asked me if I would accept working 2 days at the rate that fit into their budget.   I happily agree to the terms because it was exactly what I needed as I transitioned back to work.   What I re-learned is that you can go back to a client or company, especially if you have built up credibility there, and it helps to have more than one person vouch for you.   Finally, I re-learned the importance of having set non-negotiables.   As I was negotiating on the phone call, I made sure to pull them up and have them stare right at me!   Now, if you’re willing to share, I’d like to know what was the last career transition that was spurred by a life event for you? How did you manage to pull through without compromising on what you needed? Please let me know in the comments below!   That’s it for this episode of Build. Feel free to share it with your teammates, your friends, and whomever you think might be going through a tough transition.   And subscribe to our YouTube channel to receive more episodes.   Ciao for now!

In the last episode of Build, Paul Jarvis who is the author of Company of One and I, challenged the commonly held myth that that you need to you need to keep growing and scaling your company, otherwise you’re not innovating and you’ll soon start to stagnate.   We also debunked myths related to it such as falling prey to a big competitor and needing to be a leader who cannot fail.   The big takeaway was to question growth for growth’s sake.   The episode might also have brought up a number of questions for you like, “What about me? I work in a BIG company! Does that mean I’m not innovative? Do I need to run a one-person business? Do I have to be ant-growth?”   Absolutely not!   The Company of One doesn’t mean to be prescriptive or claim that there is only one way of doing business. Rather it’s building awareness for what is changing, and how those changes could help you. For example, if you are looking for more flexibility and freedom, you could work remotely or you could build a lifestyle business.   And if you’re still wondering, “How Poornima and Paul? How do I do these things?”  Well, tune into today’s episode. In it, we share some of Paul’s proven best practices.   As you tune in to this episode you’ll learn the following from Paul:   Why studies of companies often deviate from best practices, and what really happens when companies grow too quickly Why Paul killed off profitable products and lines of business The “gotcha” moments Paul went through as he was building his company—how they have served as proof for his best practices How you can apply the Company of One mindset to a big company   “A company of one isn’t just a one-person business. It’s not anti-growth or anti-revenue. It’s just a business that questions whether growth is right for founders, employees, and customers, and for the long term success of the business.” — Paul Jarvis   Want  to receive a copy of Paul’s upcoming book Company of One?   If you become a patron of Build on Patreon at the Silver or Gold tiers, I’ll make sure you receive an e-book copy of Paul’s book as well books from other authors I feature on the show. And if you’re one of those who loves a signed copy of a hardcover, then consider being a Platinum Patron. To become a patron visit Build’s Patreon page here.   -- Build is brought to you by Femgineer (http://femgineer.com/). --  Femgineer's Confident Communicator Course 2019 is coming up! To learn more visit: https://femgineer.com/confident-communicator-course/ --  Enjoyed this episode and want to support the show? To become a patron of the show visit: https://www.patreon.com/build

Happy new year! I hope your 2019 is off to a great start :) If you’re curious what I’ve been up to and what I have in store for 2019, I’ll tell you right off the bat, I do not set goals or resolutions at the start of the year. Instead, I review my progress every quarter to see what I want to keep doing, what experiments I want to run, and what I am going to cut or put on the back burner! Taking a broad approach has served me well in running my business, balancing it with the ever-growing demands on my time as a new mom, and most importantly, managing overwhelm. So I won’t be sharing my goals for 2019 or if I’ve resolved to exercise more or less. And I certainly won’t be telling you to do more ;) But I get that there may be other people in your life who are going to be bombarding you with messages around setting resolutions and goals as it relates to your career and personal life. Don’t get me wrong, resolutions and goals serve as great guardrails, but there’s no need to artificially set them at the start of the year. So is it OK to not always be growing personally and in business? Well, if you’ve been tuning into Build for a while, you know I love to bust myths and misconceptions on it, as they relate to building products, companies, and your career in tech. To kick things off for the show’s fifth year, I thought we’d start with one of the biggest myths around building a company: you need to keep growing and scaling, otherwise you’re not innovating and you’ll soon start to stagnate. This is a BIG myth that permeates company culture in tech, but, as it turns out, you don’t always need to grow, and continual growth isn’t always desirable. In today’s Build episode, we’re going to be debunking this myth, and to help us out, I’ve invited Paul Jarvis, writer, entrepreneur, podcaster, designer and online course teacher. Paul is the author of the new book Company of One: Why Staying Small Is The Next  Big Thing For Business. As you tune into today’s episode you’ll learn the following from Paul: How you went from being a designer to an entrepreneur How he started a service-based business and slowly transitioned to offering products Why he decided to not build a BIG business and the concerns he had around his decision 4 myths around building a big company Why it’s OK to stay small  In next week’s episode, Paul will share some best practices around building a company of one. -- Build is brought to you by Femgineer (http://femgineer.com/). --  Femgineer's Confident Communicator Course 2019 is coming up! To learn more visit: https://femgineer.com/confident-communicator-course/ --  Enjoyed this episode and want to support the show? To become a patron of the show visit: https://www.patreon.com/build

Last week on Build, we shared what allyship is and why it can help build inclusive workplaces. Anytime new approaches like these come out our defenses go up because it can be challenging to change mindsets and best practices. Plus there’s some fear around what the unintended consequences will be.   I hear ya!   Here’s the thing about allyship, you don’t need to get the green light from someone at the top or put in a ton of effort to make an impact. Turns out there are everyday actions that can benefit your team and workplace and make you a better ally.   In today’s episode, we’ll be sharing them with you to help you get started as an ally!   To help us out, I’ve invited Karen Catlin, co-author of Present! A Techie’s Guide To Public Speaking, a leadership coach, and an advocate for inclusive tech workplaces. You may recall seeing Karen in a few episodes from last year on mentorship.   I invited Karen back on to the show to talk about the work she has been doing coaching allies.   Given Karen’s rich career in tech spanning 25 years, she has a lot of experience to draw from, and it has inspired her to help other become better allies and create inclusive workplaces.   Here’s what you’ll learn as you watch today’s episode:   How You Can Get Started Being An Ally How Karen went about testing a number of simple everyday actions people can take to being an ally 3 simple everyday actions you can start to take immediately How Companies Have Benefited From Allies Taking Simple Everyday Actions A Best Practice For Being A Better Ally In Your Community   Want to get in touch and learn more from Karen? Reach out to Karen Catlin on her website Follow Karen on Twitter and follow Better Allies on Twitter to get more simple tips Sign up here to be notified when her new book is out, and receive 5 simple actions each week to create a more inclusive workplace -- Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.   --   ## 3 Simple Everyday Actions You Can Do To Be A Better Ally And Create An Inclusive Workplace Transcript   Poornima Vijayashanker:                     In the last episode, we talked about what allyship is, and why it's important for helping with diversity in the workplace today. If you missed that episode, I've included a link to it below this video. In today's episode, we're going to dive into some best practices on how you can become a better ally through simple, everyday actions. So stay tuned.                                                   Welcome to *Build* brought to you by PivotalTracker, I'm your host Poornima Vijayashanker, in each episode of *Build*, innovators and I debunk a number of myths and misconceptions related to building products, companies, and your career in tech. Now two big misconceptions that a lot of folks have when it comes to being an ally for diversity is thinking that they need to have a green light from some high level executive in order to have their initiative come out, and thinking that the initiative has to make a big impact in order to even pursue it.                                                   Well it turns out that there are some everyday actions that you can do that will cause a ripple effect and improve diversity in your workplace, and we're going to share what those are in today's episode. And to help us out, Karen Catlin is back. Karen is my co author for our book Present, she's also a leadership coach and an advocate for diverse and inclusive workplaces. Thanks for coming back on the show.   Karen Catlin:                     Thanks so much for having me again.   What Allyship Is And Why It’s Important   Poornima Vijayashanker:                     Yeah, so let's do a quick recap for people who might be joining us. Tell us what allyship is, and again why it's important today.   Karen Catlin:                     Mm-hmm (affirmative), so allyship is simply using your position of privilege to make more inclusive workplace, and help other people be successful if they don't have quite as much privilege as you. And this is so important today, because we have a war on talent, it's hard to hire people so you want to cast a wide net and keep those people once you've hired them, keep them productive and working hard at your company, and stayed, staying there.                                                   And, there are all these studies showing the economic benefits, benefits of improved innovation, problem solving, and decision making. So that's why it's important.   How You Can Get Started Being An Ally   Poornima Vijayashanker:                     Yeah. So let's talk about how people can get started, because I'm sure there's people in our audience who would love to get started as an ally.   Karen Catlin:                     Yeah, so it's really not that hard. And I love the way you started out saying you don't have to have a huge initiative, you don't have to be the VP of people at your company, or head of diversity and inclusion to start being an ally. You simply I think need to just start paying attention to what's going on around your workplace, and raising awareness yourself, and if you're not really aware of like what are some of the things I could be doing, it's fine to ask someone who is an underrepresented gender, or minority, just ask them for some feedback of what are some of the challenges you're facing, and what's one thing I could be doing to help you out?   How Karen Catlin Went About Testing Simple Everyday Actions People Can Take To Being An Ally   Poornima Vijayashanker:                     So in your upcoming book, you provide a myriad of best practices, but before we dive into some of those, let's talk about how you went about testing these practices.   Karen Catlin:                     So I start testing these ideas actually on Twitter.   Poornima Vijayashanker:                     OK.   Karen Catlin:                     About four years ago, I started a Twitter handle called @betterallies. And it was anonymous, it still is anonymous until this show actually.   Poornima Vijayashanker:                     Yeah.   Karen Catlin:                     And I started tweeting simple, everyday actions that someone could take to create a more inclusive workplace. And my whole goal was that I didn't want it to be, you didn't have to feel like you were the head of people at your company, or head of diversity and inclusion to make a difference. It really was something that the normal person could do. So I started tweeting these ideas based on my experience working in tech, based on coaching clients I had, as well as the research that was being published at the time of the challenges that are happening in tech workplaces as well as other workplaces by people who are underrepresented.                                                   Based on the reaction, I kind of started realizing, OK that works, that's helpful, that's not so helpful, and where it was helpful it was really helpful, and I started getting again, positive reinforcement that these messages were making a difference to the people who were consuming them. And checking out my Twitter handle too it's like, there's some, you can use Twitter Analytics to find out a little bit about your demographics.   Poornima Vijayashanker:                     Mm-hmm.   Karen Catlin:                     And I have about 50% followers who are men, 50% women, so I know that there are a lot of men who are paying attention to this and appreciating the content.   How Companies Have Benefited From Allies Taking Simple Everyday Actions   Poornima Vijayashanker:                     Nice. I know you've coached some men, so do you mind sharing maybe one or two examples of how these best practices have helped their team, or their company?   Karen Catlin:                     Sure. One that's just so memorable to me is I was coaching a man about, he wanted to hire more diverse talent for his team, and we started talking about just different aspects. I asked him just so how does the team socialize today, like you know, to go out to lunch or after hours? What's social life like for the team? And he looked at me, and he said, oh, you mean I probably should've told those guys going to the strip club for lunch last week that that's not cool? I'm like yeah maybe that wasn't exactly the most inclusive social event.                                                   He honestly like, bless him, he just hadn't realized how other people might feel that they couldn't go out to lunch that day with some of the team members, right. Another example is some of the language we use, and I know Pivotal Tracker I was reading a blog post that they now have something in their daily stand up, and in their bill process for the week called the Inclusion Thing of the Week.   Poornima Vijayashanker:                     Oh, cool.   Karen Catlin:                     And they just come up with the idea of something they can be doing to be more inclusive, and they talk about in their daily stand ups and everything, and one of them was simply don't use the word “guys.” Some people may be thinking, “Wait a second Karen, what do you mean? Guys is gender neutral, we use it all the time.” To them, I always like to say well if you were a woman, you need to use a public restroom, and there was a door marked guys, do you go in? Probably not.                                                   Or if someone were to ask you, a man, how many guys did you date in high school? They're not thinking women, right there, right? So “guys” is not gender neutral, so that's another thing that as Pivotal Tracker learned is a simple thing they could do. As I've started coaching other people too, examples come up such as, “Well what's your spirit animal?”                                                   Well maybe that's not very inclusive because spirit animal is actually an important part of some Native Ameri

As the year comes to a close, you’re probably getting ready to attend a holiday party, maybe your company’s. And maybe you’re concerned about what to talk about with your teammates and boss. Diversity and inclusion may be hot buttons to stay clear of, especially with people scrutinizing practices and scoffing at the benefits.   But you know it’s important…so what can you talk about? How can you set your team and company up to see a change next year?   Allyship.   Wondering what it is and how to be a better ally? Well in today’s episode, we’ll cover what allyship is and how it can help you build a more inclusive company.   To help us out, I’ve invited Karen Catlin, co-author of Present! A Techie’s Guide To Public Speaking, a leadership coach, and an advocate for inclusive tech workplaces. You may recall seeing Karen in a few episodes from last year on mentorship.   I invited Karen back on to the show to talk about the work she has been doing coaching allies.   Given Karen’s rich career in tech spanning 25 years, she has a lot of experience to draw from, and it has inspired her to help others become better allies and create inclusive workplaces.   As you watch today’s episode, you’ll learn the following:   What an ally is and what allyship is How people can develop an awareness for allyship Why you don’t need to be a leader to be an ally in your company Why men care about being an ally How to spot or approach an ally to work for Want to get in touch and learn more from Karen? Reach out to Karen Catlin on her website Follow Karen on Twitter and follow Better Allies on Twitter to get more simple tips Sign up here to be notified when her new book is out, and receive 5 simple actions each week to create a more inclusive workplace -- Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA. -- ## How Being An Ally Can Help You Create An Inclusive Workplace Transcript   Poornima Vijayashanker:         You've probably read a number of headlines around discrimination in tech. Despite all of the diversity initiatives, it seems like change is pretty slow. So, what can we do to make change faster, both in our teams and our companies? Allyship. If you're not familiar with what allyship is, well, in today's *Build* episode we're gonna talk about it. So stay tuned.                                 Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host Poornima Vijayashanker. In each episode of *Build*, innovators and I debunk a number of myths and misconceptions related to building products, companies, and your career in tech. As you're well aware of, diversity is a hot topic today. There are a number of practices, but people are scoffing at their benefits and they're wondering if there can really be anything done in the near term.   Well, there is a new approach called allyship. In today's episode, we're gonna share how allyship can help you and your company. To help us out, I invited Karen Catlin. Karen is my co-author on our book, Present. Karen is also a leadership coach and an advocate for inclusive tech workplaces. In the episode today, we're gonna be talking about what allyship is, why it's important, and in the next episode, we'll be sharing some of the best practices that you can put in place every day.   Karen Catlin:                  Thanks so much for having me on the show again, Poornima.   Poornima Vijayashanker:         Yeah.   Karen Catlin:                  It's great to be here.   Why Diversity And Inclusion Have Been On A Decline In Tech For Two More Than Two Decades   Poornima Vijayashanker:         Thanks for coming on. You've had a rich career in tech. Why don't you share with us what you've done, as well as problems you've experienced over that time?   Karen Catlin:                  Yeah, so I spent about 25 years working in tech. I started out as a software engineer writing code for a living, and over time moved into management roles, and eventually into executive leadership. Most recently, I was a VP of Engineering at Adobe Systems. During that time, I definitely saw this interesting thing happening where there was a decline happening in the number of women coming into the field. There's a lot of research that backs this up, but there are just fewer women studying computer science. Not that that's the only way you get into tech, but it is definitely a key way, here in Silicon Valley, to get into tech.                                 So, there's a decline happening with the number of women who are into the field, and at the same time, women leave tech at twice the rate of men at that mid-career point. As a result, over the 25 years that I spent working in tech, I really saw the impact. I saw that there were a lot fewer women around and less diversity in general.   Beliefs That Have Held Leaders Back From Creating An Inclusive Workplace   Poornima Vijayashanker:         Were there specific problems that maybe you incurred or you saw happening within the companies?   Karen Catlin:                  Yes. And I worked for some really good companies, so I don't wanna throw my companies under the bus that I used to work for at all. But I will say that most of the men I worked with really, firmly believed that their company was a meritocracy, that you got ahead based on your merits, that if you worked hard and did good work you'd be recognized and promoted. But the numbers just really didn't back that up. In any company there are more women in the entry level, and as you get up to the C level, it just declines like a pyramid. So, definitely there was something going on.                                 Personally, some of the things I witnessed...and I think this will resonate with a lot of women who are watching this, is something called bro-propriation where you say something in a meeting, as a woman, and it's a pretty good idea but it kinda falls on deaf ears, doesn't really go anywhere. And then in the same meeting, a little bit further on, somebody says the same thing, usually a guy because there's mostly men in the meetings. A guy says the same thing in the meeting, and gets all the credit. We call that bro-propriation, because a bro has appropriated your idea, of course. That happened to me so many times.   Examples of Unconscious Acts That Contribute To A Lack Diversity And Inclusion In The Workplace                                 Then there's also this thing, and it still happens to this day, where people give me what is called an unconscious demotion. An unconscious demotion...I bet this has happened to you, too. You meet someone for the first time and you might say, "Oh yeah, I work in tech." And they say, "Do you work in HR or marketing?" That's an unconscious demotion. Nothing wrong with those fields at all, but if you're a woman who's already in a very male dominated field, like engineering, computer science, tech in general, it's like this yet another reinforcement that you don't belong there. That's just not cool.                                 It happened to me just a couple months ago. I was visiting my husband at his office and I met one of his new colleagues. Sure enough, he said, "What do you do?" I said, "Well, I used to work in tech, was VP at Adobe for a long time." And just told him something like that. And said, "Oh, well at Adobe, were you in marketing or HR?" I mean, literally, he said those words, and I just kind of...I wanted to punch him. But I ended up just sort of smiling and saying, "Actually, I was a VP of Engineering."                                 So those are just a couple examples of things I've seen. I could share some more, but I think you probably have some more questions you wanna get to.   Poornima Vijayashanker:         Yeah, of course. It's unfortunate that you're experiencing this and seeing this happen inside of your companies and other companies. Were there things that you were also seeing in the community at large over the years?   Karen Catlin:                  Yes. Definitely started seeing...First of all, in support of women as well as other kinds of diversity, there's a lot of activity going on, a lot of conferences, a lot of discussions, a lot of research. All of that's great. And I'm starting to see men wanting to also really get involved and help with diversity initiatives, help support women in their companies, and so forth. I saw that first hand. I also saw it at places like the Grace Hopper Celebration.   The Grace Hopper Celebration...I mean, you and I know. We've been there a number of times—   Poornima Vijayashanker:         It's the largest technical conference for women.   The Origin Story of Better Allies: The Bingo Card At Grace Hopper 2014   Karen Catlin:                  Yes, exactly. In 2014, there was something called the Male Allies Panel. It was a panel of men who were leaders at their company, and talking about what they did for women in terms of allyship, to support them, to champion them, and so forth at their workplaces. Unfortunately kinda fell flat. It fell flat because ahead of time, some women were upset that men were taking up valuable stage time at this conference, right?   Poornima Vijayashanker:         Sure. Yep.   Karen Catlin:                  Some women also were concerned that these men really weren't the best allies.   Poornima Vijayashanker:         OK.   Karen Catlin:                  So they created a bingo card. They created a bingo card of phrases they expected those men to be saying that would show exactly how far they still had to go to become real allies. They handed the bingo card out, right? And of course, during that panel, the men were saying different things and falling short, and the women were checking off those bingo squares and started yelling bingo at different points during the panel.                                 Now, when I heard about this...I wasn't at that panel, I sort of was following it on social media. Wh

Last week on Build, we shared why it instead of rebuilding or redesigning an existing product, it might make sense to build a brand new product, and we walked you through how some folks on the Pivotal Tracker team arrived at their decision.   When you start building a new product, you have the best of intentions to revise old processes and move away from bad habits. But it’s easier said than done. So this week we’re going to share some best practices for keeping a new product on track!   And to help us out Lisa Doan and Vera Reynolds are back! You’ll recall Lisa is a product manager at Pivotal Tracker, and Vera is a software engineer at Pivotal Tracker.   As you listen to today’s episode you’ll learn the following:   Why it’s important to set a mission and vision for a product and what happens when you don’t What being user-centric looks like in practice How to create a balanced team and have members weight in on decisions during planning meetings How to hold yourself and your team accountable inside a larger organization How to remind people of best practices How to go about testing a new product --  Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.   ## 5 Best Practices For Keeping A New Product On Track Transcript   Poornima Vijayashanker: In the last episode of *Build*, we talked about why, instead of doing a rebuild, or a redesign, it may make sense to build a brand new product for your company. If you missed that episode, I've included a link to it below this video.                           In today's episode, we're gonna dive into some of the best practices for keeping that new product on track. So, stay tuned.                           Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. In each episode of *Build*, innovators and I debunk a number of myths and misconceptions, related to building the products, companies, and your career in tech.                           In today's episode, we're gonna be sharing a number of best practices to keep a new product on track, as you're building it, and to help us out, I've invited Lisa Doan, who is a Product Manager at Pivotal Tracker, as well as, Vera Reynolds, who is a Software Engineer.                           Thanks for coming back on the show, Ladies.   Lisa Doan:  Thanks. Happy to be here.   Poornima Vijayashanker: Yeah. Let's do a quick recap from the last episode on why you decided, instead of doing a rebuild or a redesign, to build a new product.   Vera Reynolds: Yeah. So, initially we thought we were just gonna rebuild Tracker, and when we went out in to the world, we realized that the problem space was just way too big and that net was cast too wide and so we need to follow the pain and find what were the most effective things we solve for our users. You have to understand that Tracker does what it does well. They are other competitors, absolutely, I'm not here to toot my own horn but it's a pretty good product. And so we found that there are other problem spaces that we could talk that are adjacent to Tracker that could complement it in a nice way and so that's we ended up where we are.   Poornima Vijayashanker: OK, so whenever we have the chance to build something brand new we want to start with the best practices, new best practices. I'm sure you've both experience this as well as you were assembling your team. What were some best practices and how did you go about learning them.   Lisa Doan:  So on the product side we had to adopt a lot of new practices. So when Tracker was built back in 2006, product was less of a thing but since then, things like lean startup have emerged, lean product, user centered design and we needed to catch up on those things. And so we brought in an innovation coach who helped us learn how to do experiments and really think about product in a lean fashion. And so we've been doing a lot of practices around that.   Poornima Vijayashanker: And I remember in the last episode you talked about how your innovation coach also helped you with a mission and a vision   Lisa Doan:  Yeah.   Best Practice #1: Set a Mission And Vision For Your Product   Poornima Vijayashanker: So how did that come about or what did that look like?   Lisa Doan:  Sure, so when she arrived we had been doing endless research and so she recognized that we were paralyzed and that the first thing we needed to do was pick a direction and that's what the mission and vision were tools to help us do. Where they came from is, the designer and myself had done plenty of research in the years prior about what the major problems our users were facing on Tracker. And so we had a couple ideas of what we wanted to address with the new tool and so those were incorporated during a workshop where everybody on the team was throwing out their ideas and what they wanted this new tool to be, how they wanted to solve problems for users. And after, I think a whole morning of just workshopping it over and over we finally arrived at a mission that everybody could really agree on.   Poornima Vijayashanker:                     So what was the mission that came out of this?   Vera Reynolds:                I'm gonna paraphrase it a little bit. Our missions to empower individual contributors on a team to align around shared goals.   Best Practice #2: What Being User-Centric Really Looks Like   Poornima Vijayashanker: So I've heard you through around user centric a lot. It seems like it's a new direction that you're going in. How is this different from what you were doing before with agile.   Lisa Doan:  Tracker was born by engineers for engineers and for the majority of our span as a team, we've been a very engineering centered. A lot of our leadership is former engineers who worked on the project. All of our product manager back in the day were extremely technical. I was the least technical PM and I have a degree in computer science. And so we always had this mindset of doing the best engineering possible but we were less focused than we should have been on what our user needs were and that's been a huge cultural shift that we've tried to instigate with our new team, which is, let’s think about the user first. Let's always question why we would build something before we build and that's a muscle that we've really had to really grow and exercise a lot is, rather than just coming up with an idea and just immediately building it is, let's go make sure this solves the user problems, validate that the user actually has this problem. And just really having a discipline around that.   Poornima Vijayashanker: Is that because the user is different so maybe you're not dogfooding it as much as a builder.   Vera Reynolds: We do actually dog food our current product. So that was one of the first, we were our own first user and I do think that helps with keeping that front of mind, but as an engineer, I've always been getting used to getting candid stories, not so much asking about why we were doing it. It may have been my experience but from what we've learned from our users, that's not unique and there's not necessarily anything wrong with that, however we feel like a balanced team where everybody is involved and has is user centric to pull it up again, provides the better product.   Best Practice #3: How To Create A Balanced Team And Have Members Weigh In On Decisions During Planning Meetings   Poornima Vijayashanker: So let's talk about those balanced teams next 'cause I think that's the thing that's new to right, in your approach. What's a balanced team.   Lisa Doan:  So we like to think about it in terms of three spheres of influence, and so you have a sphere that's very concerned with the user, and so typically that falls to a designer. And then we have the sphere that's concerned with the business and so typically the product manager has been responsible for that. And then we have the engineering side, who's concerned about, usability, who's concerned about building, using the best patterns. And so balanced team isn't about specific roles and filling them but it's that, at any given time someone can weigh in for each of those spheres. And so at some point, whenever you're making a key decision, someone should be able to represent the user, someone should be able to represent the business and someone should be able to think about technical fusibility and the engineering impact of that.   Poornima Vijayashanker: Got it. So as you're moving forward and building this product, you have each of those spheres weighing in on the decision.   Lisa Doan:  Sure, an example of that is when we go to IPM stories, and we're-   Poornima Vijayashanker: What's IPM?   Lisa Doan:  Iteration planning meeting.   Poornima Vijayashanker: OK.   Lisa Doan:  And so as a team will go through the stories that are coming up next and talk about any concerns that we might have. A good example of that now is, sometimes I'll bring a story to the team, and the engineers are capable of challenging me and saying OK, what is the evidence that we should actually build this. Whereas before the engineers were like, "OK, we'll build it." But there wasn't that conversation about what is this actually doing for the user. So it has great impact that we see.   Best Practice #4: How To Hold Yourself And Your Team Accountable Inside A Larger Organization   Poornima Vijayashanker: Yeah. So while you are a new team you have assembled, you're still operating in a bigger organization. But I know your goal was to stay more startupy and the best startups are always keeping an eye on time as well as money. So how did you hold yourselves accountable?   Lisa Doan:  When we first started we...this was a huge challenge for us. We went out and started to do research, but it became this endless research thing and there was no one asking us...well people were asking us when are you gonna build, but we couldn't tell them. We had

Happy November!   November is one of my favorite months mostly because I love Thanksgiving. Last year I had a wonderful time celebrating it with Meghan Burgain, Femgineer’s Community Manager in Bordeaux, France. We had a Frenchgiving, and had the opportunity to share how Meghan works remotely.   This November we’re going to be tackling a new theme on Build: building a brand new product.   If you’ve been building a product for a while, you know it’s natural to start accruing tech debt and product debt. And there comes a point where it becomes really hard to add new features without paying down the debt through rebuilding or redesigning the product.   However, there may come a point where neither of those makes sense, and you may be evaluating building a brand new product.   The Pivotal Tracker team recently did this. In today’s episode, Lisa Doan, who is a product manager for Pivotal Tracker and Vera Reynolds, who is a software engineer for Pivotal Tracker, are going to walk you through how they came to the decision to build a brand new product.   As you listen to today’s episode you’ll learn:   What spurred the conversation to consider building a new product Why the team chose not to redesign or rebuild the existing product What the team did to identify the problem it was solved with the new product Why the team held off on coding and building and what they did instead Why software engineers benefit from being involved in the research phase of a brand new product How to recruit new teammates to help build, and identify knowledge gaps -- Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA. -- ## Why Build A Brand New Product Instead Of Rebuilding Or Redesigning One Transcript   Poornima Vijayashanker: It can be really tempting to want to redesign or rebuild a product that's been around for a while. But often, it's much more of an undertaking to do that redesign and rebuild, and it can be easier to instead build a brand new product. The Pivotal Tracker team had to do this recently and in today's episode. they're going to share how they evaluated building a brand new product. So, stay tuned.                           Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. In each episode of *Build*, innovators and I debug a number of myths and misconceptions related to building products, companies and your career in tech. When you've been building a product for a while, it's natural that you start to see tech debt and product debt accrue to a point where it backs you into a corner and it's really hard to add new features without rebuilding or redesigning it.                           But at some point, it may not make sense to keep adding to that product and instead, you may want to build a brand new product. In today's episode, we're going to dive into why you may decide to build a brand new product instead of redesigning or rebuilding your existing one. To help us out, I've invited two lovely ladies from the Pivotal Tracker team. Lisa Doan, who is a product manager for Pivotal Tracker as well as Vera Reynolds who is a software engineer on their team. Thanks for coming on the show you two.   Vera Reynolds: Thank you for having us.   Lisa Doan: Yeah, thank you so much.   Poornima Vijayashanker: I know that Pivotal Tracker now has been around for over 10 years, has over 100,000 active users and there's just been a lot of features, and a lot that you've accomplished in the past 12 years. And so, adding to it might have been a challenge and that's why you decided to go a slightly different direction.   What Spurred The Desire To Re-Evaluate The Product                           But before we even go and talk about that new direction, let's talk about what even caused this to happen. Let's get in a time machine, go back in time. What spurred the change for a different direction?   Lisa Doan:  It was really a confluence of a lot of different things happening all at once. On the product side as a team, we were frustrated because we weren't able to really deliver major features that our customers had asked for. On the engineering side there was a lot of tech debt, and a lot of frustration working in the code base. And on the customer side, there was also a lot of frustration that we hadn't really put out major features in a long time and our product had somewhat stagnated.                           All of that led to us realizing that we needed to do something big, but there were so many things in our way that we wanted to deal with. That's kind of what led to the origin of our project.   Poornima Vijayashanker: Can you give us a timeline, like roughly when did that start?   Lisa Doan:  I think as a team we started to recognize about a year ago that something big needed to happen. It's just been a gradual process since then.   Signs That The Product Needs To Change   Poornima Vijayashanker: Looking back, can you point to maybe a cause or several causes that led to the product starting to decline?   Lisa Doan:  Sure. The product was actually born out of an internal team. Pivotal itself started as a consultancy. Back in 2006, there wasn't a great backlog management tool, and so the engineers built one that suited their needs. But because of that, Tracker was always a bit of an accidental product. We built it for our own needs. But, clients would then ask to take it home after engagements and then it just grew virally there.                           Because of this, we never really had a clear mission or vision. It was just something that we built that we had a problem and then we solved for. That over time became a problem because we added all these different customers, but they had varying problems and we didn't have anything to pin our work too. We didn't have a strong opinion on which direction we should take the product so that led to lots of different features that were kind of scattered in how they addressed user problem.   Why Choose NOT To Redesign Or Rebuild A Product   Poornima Vijayashanker: I know in the next episode we're going to talk a lot about how you changed your engineering and your product team's whole process, so we'll pause on that. What I want to talk about now is why you decided against redesigning and rebuilding Pivotal Tracker.   Lisa Doan:  In maybe October of last year, as a group we had finally realized that we were at this point that we needed to make a big call on something and the initial thought was like, yeah, let's just rebuild. it's just so much easier, the code base is so challenging. No one wants to work in it anymore. Because it was an accidental product, there was never a strong architectural vision so it was all sorts of different tech stacks everywhere.                           So, we decided that we were going to have this team go out and they would re-envision Tracker. We even called it Tracker, but Better. Really quickly we realized that wasn't such a great idea. Tracker was built for a specific problem, which is backlog management. That was the problem in 2006.                           But here in 2018, the problems are different. There are lots of different backlog management tools that any team can choose and tailored to their specific needs, and Tracker has kind of falling behind on some of those things. At the same time, the problem that all of our customers have is around knowing what to build.                           Teams now know how to build software pretty well and there are lots of tools they can choose from, but how do they choose the right product to build? Tracker doesn't solve for that in any way at all.   Two Paths: Maintaining The Existing Product And Building A Brand New One   Poornima Vijayashanker: So, you make the decision that you're going to build a new product, and the Pivotal Tracker team is going to continue building that because there are two different needs, kind of two different missions and visions. Let's dive into what happens next with the new product.   Lisa Doan:  One of the goals for our team was to go back and reconnect and realign with a larger organization. Tracker kind of had its own destiny within Pivotal, and we wanted to make sure that both Tracker and whatever initiative we started with our team were more aligned with Pivotal. One thing we did is, we went back and talked to our leadership and we talk to other users within the organization to make sure that we were following their pain and solving the right problems for them, whether it's within Tracker or within your products.   Poornima Vijayashanker: You're at a point now where Tracker is continuing to be built by a team. You form a new team to discover what this new product is going to have in it.   Lisa Doan:  Sure.   Identifying THE Problem To Solve   Poornima Vijayashanker: So, what are some next steps?   Lisa Doan:  From Tracker, we knew there was a big space of problems that our users were dealing with, and so we wanted to really dig into that. Another goal that we had was bringing our team closer to the Pivotal Organization. Overtime, Tracker had sort of become a silo on its own, so part of our team's goal was to reconnect with the broader organization and make sure our product is aligned with that.                           So we went out and talked to various stakeholders. We talked to the CEO, we talked to the leadership in cloud and R&D and understood where they think the business is going and how we could support that. We had to rebuild a lot of those bridges, but it's been extremely valuable because they provide us input that we didn't have previously that helps guide us in terms of the decisions we make when we're building this new product.   Poornima Vijayashanker: What became the focus of this new product?   Vera Reynolds: To get a little meta, we've been using Tracker to develop Tracker. It's a great tool, and it allows teams to go fast. However,

In last week's Build episode, we talked about why if somebody doesn't understand your explanation for a technical concept, it's not OK to just tell them to look it up or Google it. We also covered the effects of doing this, the main one being that you don’t come off as someone who is credible!   In today's episode, we're going to dive into the specific tactics for how you can explain abstract technical concepts to an audience of either lay people or one that may be a little bit more advanced.   Anne Janzer is back to help us out. Anne is a prolific author and recently published Writing To Be Understood: What Works and Why.   Here’s what you’ll learn as you listen to today’s episode: What things we need to take extra time to explain How to gauge your audience’s level How to handle mixed audiences and explain in a way that is inclusive How to avoid “dumbing down” an explanation Why writing out an explanation is harder than sharing it verbally How to pick analogies that are going to resonate with your audience Which contexts to apply these techniques to -- Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA. -- # 3 Techniques To Improve Your Explanations And Be Understood Transcript   Poornima Vijayashanker:           In the previous episode of Build, we talked about why if somebody doesn't understand your explanation for a technical concept, it's not okay to just tell them to look it up or Google it, and if you missed the episode and the reasons why it's important for you to explain, then I've included a link to it below. In today's episode, we're going to dive into the specific tactics for how you can explain abstract technical concepts to an audience of either lay people or one that may be a little bit more advanced. So, stay tuned.   Poornima Vijayashanker:           (pause)   Poornima Vijayashanker:           Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. In each episode, innovators and I debunk a number of myths and misconceptions related to building products, companies, and your career in tech. Now, we've been talking about the importance of breaking down abstract technical concepts as the person explaining them. In the last episode, we uncovered why it's important as the explainer to take the time to explain things in a way that your audience is going to understand.   In today's episode, we're going to dive a little bit deeper to give you specific tactics that you can use the next time you're presented with having to communicate something to a teammate or to a lay audience.   Poornima Vijayashanker:           And to help us out, Anne Janzer is back. She is the author of a number of books that range on topics from writing to marketing, and she's kind of a cognitive science geek. So, thanks again for joining us today, Anne.   Anne Janzer:        Thanks for having me back.   Poornima Vijayashanker:           Yeah. So, I know in your upcoming book, you've got a range of techniques, and I want to kind of tease out just a few for our audience, and I know it focuses on writing, but I'm sure a lot of these techniques apply in a number of contexts. Maybe you can share with our audience some of the contexts that you think these techniques could apply to.   Anne Janzer:        Really, yes, I think they apply any time you've got to communicate about a complicated topic to someone who doesn't share the same background you have on that topic. So, it can be whether you're writing an email to somebody or presenting to investors, maybe trying to explain to your family what the heck it is you do for a living.   Poornima Vijayashanker:           Yeah.   Anne Janzer:        That can be a challenge if you work in tech, I know. There's all sorts of things, and it certainly applies to ... most of this applies to writing as well as speaking. The challenge with writing that's different than speaking is that when we're speaking, I have my body language, I have my voice, and I can see if you're checking out, checking your mail, or confused.   Poornima Vijayashanker:           Right.   Why writing out an explanation is harder than sharing it verbally   Anne Janzer:        It's very obvious, and when I'm writing, the reader's not present when I write, and the writer's not present when they read. So, everything's just on the paper. So, you have to work harder to really advocate for the reader as you are doing the work of planning and writing and revising so that it really, you can be almost present with them.   Poornima Vijayashanker:           So, let's talk about the things that we need to take extra time to explain.   Anne Janzer:        Right, so, here's the main thing. It's abstract topics.   Poornima Vijayashanker:           Mm-hmm (affirmative).   Anne Janzer:        Technology is itself just layers of abstraction, right, and you work in this silo of abstraction, and that person works in that silo of abstraction. Maybe I know storage, and you know Cloud infrastructure, right? They're really related things, but they're different things, and when people are faced with abstract ideas, this is part of human reasoning. We are animals that abstract things.   Anne Janzer:        There's a couch, and there's a table, and they're both furniture. Now, everybody's comfortable if I talked about furniture, you know what I'm talking about, but when it gets to technology, you can get to the point where people aren't comfortable with that, and so what we need to do is try to figure out a way how to take something that is abstract and sometimes intangible. It's just an idea, and make it concrete so that people can understand it.   What things we need to take extra time to explain   Poornima Vijayashanker:           Now, what are the specific things that we need to take extra time to explain?   Anne Janzer:        So, when we work in the tech industry, we're dealing with abstract ideas all the time, abstractions, and it's just layers and layers and layers and abstractions, and so we come up with a lot of words and terms and jargon that is short hand, and it's absolutely essential for us to communicate with each other, right, but it's not always essential for us to communicate with someone outside of our field.   Poornima Vijayashanker:           Mm-hmm (affirmative).   Anne Janzer:        And that is often the biggest barrier for people understanding what we're talking about when we're talking about technology, is the words that we use, the jargon and the abstractions that we use. So, that is the thing that the very low hanging fruit to take care of when you're writing or speaking, is what abstractions and what jargon am I using that could cause problems?   Poornima Vijayashanker:           Yeah. I've also noticed for a lot of my students and audience that they may have something that's internal to their company. So, yeah, sure something like HTML, okay, we get that that's an abstraction because of the acronym. It's kind of buzz wordy, but then they have something internal where they say, oh, we use this thing called an OKR, and they just assume everybody in their company knows it. Somebody on the outside's like, OKR, what is that, right?   Anne Janzer:        Right.   Poornima Vijayashanker:           Yeah, so how can we kind of figure out what things we may think are specific to our organization or even our team, are not necessarily commonplace.   Anne Janzer:        Yeah, so you have to get a little loose. I like to print out what I've written, and maybe highlight anything that is term, an abstraction, maybe anything that is abbreviated, capitalized, acronyms. You know what they are.   Poornima Vijayashanker:           Right.   Anne Janzer:        And for each of them, you need to ask two questions. Is it maybe, is it possibly unfamiliar to my audience, and is it necessary? So, if it's necessary to use it, the only way to talk about it, or everybody talks about blockchain is blockchain, right? Okay, I had to use the word blockchain. There's a law, right?   Poornima Vijayashanker:           Yeah.   Anne Janzer:        I have to use it. If it's necessary to use it, but it might be unfamiliar, then it is on you to define it or show an example the first time you use it, or use it in such a clear context that there's no confusion. If it's unnecessary and unfamiliar, if there's another way to use it, get rid of it. You're just adding unnecessary cognitive load to the reader.   Anne Janzer:        So, necessary or unnecessary, familiar or unfamiliar. I mean, you don't have to strip out furniture. You know, you don't have to strip out acronyms or things that people really should all know who are in your audience, but you do need to be anything that, yeah, maybe they know it, but maybe they haven't encountered it that many times.   Poornima Vijayashanker:           Right.   Anne Janzer:        So, they're going to have to do a little bit of extra work to fill in the blanks while they're listening to you or reading.   Poornima Vijayashanker:           So, is there a way we can gauge the audience level, because I know a lot of times people assume, well, I'm talking about this new framework, this new technology, and it's in the title of my talk. This conference is about this talk. So, I just assume everyone coming here is going to know what this is. Why do I really need to take an extra 30 seconds, one minute, PowerPoint slide, et cetera to explain this? Won't it seem like I'm "dumbing it down" for them?   How to avoid “dumbing down” an explanation   Anne Janzer:        Yeah, right. I think you don't want to dumb down for people. You want to respect their intelligence, but you also have to remember someone at the conference just came out of three other sessions. Someone picking up your article may be like, wait. Why do I want to read this? It's in the title. I forgot. I mean, people come from very interruptive and context changing d

Confession time…   A few years ago when someone asked me to explain a technical concept and I couldn’t successfully get through to them or didn’t have time, I would send them this link. ;)   And it seemed funny the first couple of times I did it.   It wasn’t until someone did it to me that I realized how obnoxious it was. I eventually stopped asking for them for help, because I knew they weren’t very good at explaining things and didn’t have the patience to help me.   I also realized that I didn’t want to be like them. I needed to get better at explaining technical concepts. Ever since then, I’ve been on a quest to improve how I communicate technical concepts when I write and speak to people and audiences of varying levels.   Part of my discovery led to me Anne Janzer. Anne is a prolific author who has recently written a book called Writing To Be Understood: What Works And Why, and she’s also a cognitive science geek!   I sat down with Anne to debunk the misconception that if someone doesn’t understand a technical concept immediately, then it’s their fault. They're too much of a layperson, and they should look it up. But it’s actually the explainer who needs to do a better job of explaining, and in today’s *Build* episode, we’ll explain why!   In next week’s episode, we'll provide techniques on how you can get better at explaining technical concepts to a mixed audience or to a layperson.   As you listen today’s episode, you’ll learn the following:   Why people on the receiving end of an explanation find the explainer to be less smart if the explanation cannot be easily understood Why people are bad at explaining technical concepts using simple language Why we assume our audience knows what we’re talking about Why people may not get our explanation The three questions to ask yourself about your audience before you communicate with them Why we have a tendency to overexplain Why overexplaining isn’t helpful either and being brief is better   -- Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA. -- ## Why Doing a Bad Job of Explaining Technical Concepts Hurts Our Credibility Transcript   Poornima Vijayashanker:  Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. In each episode, innovators and I debunk a number of myths and misconceptions related to building products, companies and your career in tech.   Now one huge misconception that we all face is that when we're trying to explain a technical concept, if someone doesn't immediately get it, we think, you know what, it's their fault. They're too much of a layperson, and we advise them to just look it up. Turns out, the person who's explaining the technical concept, it's actually their fault for not explaining it.   I know that might seem counterintuitive, but in today's episode, we're going to explain why the onus falls on the explainer and in a future episode, we'll give you some techniques on how you can get better at explaining technical concepts to a mixed audience or to a lay person. And to help us out, I've invited Anne Janzer, who is the author of a number of books ranging from writing to marketing and she's kind of a cognitive science geek. Thanks for joining us today, Anne.   Anne Janzer:    Thanks for having me Poornima. I'm happy to be here.   Poornima Vijayashanker:   So you've got a new book coming out and it's all about explaining technical concepts and being understood. Maybe you can dive into the origin story for what inspired you to write this book.   Anne Janzer:    Sure. So, the title of the book is *Understood*. So it's about writing to be understood and it came from two things in my life. One, is that I spent a lot of my time in the technical industry as a freelance marketing writer working for dozens and dozens of different companies trying to explain these really geeky technologies to a business audience. So that's familiar to most of the viewers.   But second, I also, as you said, I'm a bit of cognitive science geek so I love to read all these books about the brain and psychology and behavior and behavioral economics. You notice that some authors are really good at explaining this stuff. And you think, so there's parallels between what they do and what I was doing, which is explaining complicated, abstract topics. So are some people just like born better at this? I don't think so.   I took a close look at what these writers do, now I've called up and talked to some of them about what they do which is great. It turns out that there are just methods and techniques and approaches that we can all use to become better at being understood when we're talking about something to people who don't share our knowledge about it.   Poornima Vijayashanker:   So it's great that there all these experts who understand why this is important, but for our audience out there, they're not sure why this is important. We can dive into that in a little more detail.   Why people on the receiving end of an explanation find the explainer to be less smart if the explanation cannot be easily understood   Anne Janzer:    Yes. So you may not feel like…you may feel, well, I'm the expert. It's not on me to make sure that everybody understands. It's not my problem basically, if I'm explaining it. But it is your problem. It really is and the cognitive science shows that.   When you explain something that's complicated and you use words or terms or even writing techniques that they don't understand, you are giving the audience extra cognitive load. You're making them do extra work, not to understand the thing that you're saying, but even to get through to the thing that you're trying to explain to them.   Research shows that when people experience cognitive load, certainly while reading, they don't assume that the writer is smarter, they actually assume that the writer is less smart. So when they don't get it, they don't think, gee, I must be stupid, they think, they're not so smart.   Anne Janzer:    There's a study by a guy named Daniel Oppenheimer, who's now at Carnegie Mellon, but he did this back when he was at Princeton. I have to read the name of the study because it totally illustrates what it's about. “Consequences of Erudite Vernacular Utilized Irrespective of Necessity or Problems with Using Long Words Unnecessarily.”   Poornima Vijayashanker:   Nice. Yeah.   Anne Janzer:    Which is great. And in the study they had people look at the same passage written two ways. One in a more straightforward way, one more complex using longer words or one piece sentence construction, let's say. People who read the more complicated ones rated the author as being less intelligent.   In one case, even when they knew that the passage was by René Descartes. They were reading translations and they're like, this is René Descartes from his meditations. They're like yeah, he's not that smart. If they read the more complicated one. So if you want to show up as being an expert you have to be understood. And it's on you. It's on you to do that.   Why people are bad at explaining technical concepts using simple language   Poornima Vijayashanker:   So why do you think people get into this habit of being long-winded or maybe using big words?   Anne Janzer:    I don't mean to be critical of it, because we all do it. It's a natural thing. If you work in a tech sector for a long time, you're surrounded by people who are all using these abstractions and these terms. You master the complexity of the subject. You're a part of a social group of people who have mastered that complexity. So it's natural to want to speak in a way that people around you understand, use those words.   But you need to remember that these abstractions that now come easily to you. Like now you can ride a bike, but a toddler can't ride a bike, looks up at the person riding the bike thinking, yeah, that looks really hard. So that's the situation. That you're really comfortable with these abstract terms, but if you're talking to people outside of your domain, outside of your area, those terms are much more difficult to operate with.   Why we assume our audience knows what we’re talking about   Poornima Vijayashanker:   So it's natural to evolve and get into this in crowd or you're surrounded by people who know. You kind of expect other people to know and then when they don't, you're kind of like, well, just Google it, right. So how can we get over this? This expectation that our audience just knows.   Anne Janzer:    Well, we have to remember that we suffer from the curse of knowledge, which is hard for us to remember not knowing the things that we not now know. So some of the times it's not that we're being dismissive of our audience, we're just assuming that they know the things. That these things are familiar to us are familiar to them.   So you really have to get outside of your own head for a moment and try to put yourself in the perspective of your audience. That's why the title of my book is Understood. It's not like, explaining, it's understood, because it doesn't matter what the words are coming out of your mouth or your pen. It matters how it sinks into the audience's mind.   Why we need to incite curiosity in our audience Poornima Vijayashanker:   I don't know about you, but I definitely had a few college professors, their names will go unnamed. In their 101 class, kind of expected me to know certain things or to, again, spend the time looking it up. So how can we combat that as well?   Anne Janzer:    So that story drives me crazy because the purpose of a 101 class and the job of the professor of that class is to give people enough information but also to incite their curiosity so that they can learn enough to figure out if they want to pursue that field. If they want to learn more or what is useful to them from that class.   And in many ways, we all are in that same position as that 101 teacher.

All this month, we’ve been sharing best practices around hiring and interviewing product managers. If you checked out both episodes, you might be thinking: “This is a lot of work! How can we be sure we’ll end up with a stellar product manager, and that they won’t quit in three days or three months?”   We get that hiring and interviewing are just two pieces of a larger puzzle around talent management. And of course it’s not enough to just attract top talent; there’s more that needs to be done to make sure they stay motivated and productive. So to quell your concerns and help you figure it out, we’re going to do a deep dive in today’s episode around what to do after you hire a product manager. We’ll be sharing why current practices often fall short of meeting a new employee’s expectations and some alternate best practices for onboarding, training, retaining, and evaluating the performance of product managers.   Jeana Alayaay, Director of Internal Products and Services at Pivotal, is back this week.   Here’s what you’ll learn in this meaty episode:   How to onboard a new product manager and set expectations Why you need to have a development plan ready for your new product manager and how to walk them through it Why an annual performance review is too late to check in and provide feedback, and what to do instead Why even a seasoned product manager will benefit from coaching and guidance as part of their onboarding process What success metrics look like for a new product manager How to evaluate your product manager’s performance in the midst of changes that are beyond their control Why it’s good to set granular expectations around deliverables and milestones What to do when your product manager stops performing or suddenly quits -- Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA. -- # How to Train and Retain Top Product Managers Transcript    Poornima Vijayashanker:        OK Jeana, we've covered a lot already. We've talked about some of the best practices when it comes to sourcing Product Managers, and then interviewing them. And, all of this before we even get into training, and retaining them. So, please tell me that we can guarantee for our audiences, we're going to find that mythical, or magical unicorn Product Manager.   Jeana Alayaay:      Unfortunately I don't know that they're findable. Because, I don't think unicorns are turnkey. But, I do think you can develop unicorns for your company, or your specific context.   Poornima Vijayashanker:        OK, but what if they leave in three days or three months? That's a lot of effort.   Jeana Alayaay:      Yeah, oh man. That's tough, we'll cover that. Yeah.   Poornima Vijayashanker:        OK, let's get to it then. Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. In each episode innovators and I debunk a number of myths and misconceptions related to building products, companies, and your career in tech. Now, over the last couple episodes we've been sharing some best practices when it comes to sourcing, as well as interviewing and hiring top Product Managers. But, I'm sure you're still worried if your Product Manager is going to be the right fit, or maybe you hire them only to discover that they weren't quite a top performer as you thought they were in the interview process.   Poornima Vijayashanker:        Well fear not, because Jeana Alayaay is back. You'll recall, Jeana leads the Product Management, as well as Design team. We're going to share some best practices when it comes to training, as well as retaining your top performers so that they don't just up and quit. Thanks for joining us again.   Jeana Alayaay:      Thanks for having me again.   ## Conversations to have with new product managers   Poornima Vijayashanker:        Yeah. OK, so like I said, we've taken a lot of time to kind of address the criteria for how to find candidates, and source those candidates. But then, we gotta make sure that these people are going to perform, and stick around. What do we do next?   Jeana Alayaay:      Yeah. So, I think the big thing is having a development plan that's shared with you and your Product Manager, right? I know that sounds a super simple common sense thing to do. But, it's amazing 'cause when we hire these top performers, we sort of expect them to just go on their merry way, cut wood and hull water. Then, one day they'll leave, right? We always think, "Oh, it's because it's more money," or whatever the case may be.   Poornima Vijayashanker:        Sure.   Jeana Alayaay:      But, often the feedback is, "I just didn't feel like I was growing." Right?   Poornima Vijayashanker:        Hmm, mm-hmm.   Jeana Alayaay:      Having that conversation at the beginning and saying, "Hey, how do you need to grow, how do you want to grow, and how can we have an actual development plan that puts you in the way of the opportunities to get you that growth?" Up front is really important.   Poornima Vijayashanker:        OK. What if they don't know?   Jeana Alayaay:      Then you're going to have to figure it out together.   Poornima Vijayashanker:        Mm-hmm.   ## Don’t wait for the annual performance review to check in   Jeana Alayaay:      I think that obviously folks who tend to be a little bit farther in their journey tend to have a better idea. But, you always have folks who are just starting out. I think just coming up with some things initially, and then iterating your way towards it is totally fine. I think just having a lot of checkpoints there, right? I don't mean a development plan that you check in once in the annual performance review. I mean, something that you're visiting in every one on one.   Poornima Vijayashanker:        OK.   Jeana Alayaay:      That, you look at every quarter and you say, "Are we making progress against goal?"   Poornima Vijayashanker:        Yeah.   Jeana Alayaay:      With those folks who don't know, "Hey, what are we seeing, where have we gotten feedback, what are your feelings on this now that you've sort of been in the works for a while?"   Poornima Vijayashanker:        Yeah, so let's backtrack a little bit and just talk about onboarding.   Jeana Alayaay:      Yeah.   ## How to onboard a new product manager   Poornima Vijayashanker:        Do you have some best practices when it comes to even onboarding a new Product Manager coming into your organization?   Jeana Alayaay:      Yeah. Have them spend a lot of time cross functionally at first.   Poornima Vijayashanker:        OK.   Jeana Alayaay:      Spend some time with the engineers, spend some time with the designers, spend a lot of time with leaders, those folks who, they're going to need to get alignment and decisions from.   Poornima Vijayashanker:        Right, mm-hmm .   Jeana Alayaay:      I think there's just a lot of up front networking that needs to happen, that we sort of gloss over. 'Cause we always want them to sort of jump right in.   Poornima Vijayashanker:        Right.   Jeana Alayaay:      And, just start doing things. But, that will get you only so far until relationships really come into play. And so, I always like to sort of invert that model and say, "Build the relationships first." The doing thing, that will happen.   Poornima Vijayashanker:        OK, got it. For yourself as either the Hiring Manager, or as the Manager for this new candidate.   Jeana Alayaay:      Yeah.   ## Why even a seasoned product manager will benefit from coaching and guidance as part of their onboarding   Poornima Vijayashanker:        How do you think about coaching them, or training them?   Jeana Alayaay:      Yeah. I think the first thing is to come forward with really clear expectations. One of the things that I say is, I haven't seen a Product Manager who's blown my mind in less than a year.   Poornima Vijayashanker:        OK, yeah.   Jeana Alayaay:      Let me explain more of that. Even if you bring in a fairly seasoned, or senior person, right? They just don't even know the landscape, right?   Poornima Vijayashanker:        Yeah.   Jeana Alayaay:      So much of their job is moving people in the landscape. It's like, to expect them to be here when they don't even know who those people are, is the wrong expectation to set for both of you. I think saying, "Hey, I expect you to be cutting water, and hulling water in three months. At six months, I think you're going to have a good sense of what's going on. And, at a year you're really going to start to be able to make strategic moves with people."   Poornima Vijayashanker:        OK.   Jeana Alayaay:      I think that's actually a good approach.   ## How to evaluate your product manager’s performance in the midst of changes that are beyond their control   Poornima Vijayashanker:        Got it, so kind of set some milestones. But, what if there are barriers? The company's goals change, or the product goals change.   Jeana Alayaay:      Yeah.   Poornima Vijayashanker:        Or, some giant customer comes in and takes up all of the priorities.   Jeana Alayaay:      Yeah.   Poornima Vijayashanker:        How do you kind of back channel that, or bring it back into their specific goals, or their career development?   Jeana Alayaay:      Yeah, that's a great question. I would say this sort of harkens back to what I consider to be a red flag for a Product Manager, is not asking for help. The other side of that is top performers are really great about raising their hand and saying, "I need help." Or, "I think something is changing." Right?   Poornima Vijayashanker:        Yeah.   Jeana Alayaay:      They're actually out there in the woods.   Poornima Vijayashanker:        Right.   Jeana Alayaay:      Sort of getting a sense of how the Earth is moving.   Poornima Vijayashanker:        Yeah.   Jeana Alayaay:      So, sometimes they're the best person to say, "I think the tides are changing and we should pay attention

Last week, we dug into the various product manager personas, and how to go about sourcing candidates.  This week, we’re going to talk about another critical step when it comes to hiring product managers: interviewing. Unlike interviewing engineers and designers, where you can test their ability to code and design and their responses provide tangible results, it’s harder to formulate questions related to one’s skill and abilities as a product manager that will produce concrete responses. Let’s face it—product management is more nuanced because it often requires people to have experience analyzing data and making decisions related to the goals of the business, in addition to some technical skills. Exposing the spectrum and depth of these capabilities can make interviewing product managers a challenge. For example, it maybe easy to evaluate if someone can organize a backlog of user stories, but harder to evaluate whether they are really capable of creating and prioritizing a product roadmap that balances out various business goals and milestones to an acceptable level of quality and depth for your team.   Plus a product team usually has one product manager who interfaces with many engineers and designers, so hiring the first product manager who is going to gel with all those people puts them under a lot of scrutiny.   To handle all these challenges, many companies end up crafting their interview process to resemble a standardized test that candidates end up studying for, rather than demonstrating key skills that they will be using to support the team and product. It’s no wonder some of the best candidates fall through, and companies feel stuck with a product manager who underperforms.   This episode is a must watch if you’re a hiring manager who is concerned about losing a talented product manager, or you’re a product manager who is trying to assess a company’s interviewing process. In this episode, we’ll share some best practices around interviewing and coming up with objective criteria to use when screening candidates.   Jeana Alayaay, Director of Internal Products and Services at Pivotal, is back to help us out.   As you listen to today’s episode, you’ll learn the following:   Why there is such a thing as being a bad interviewer How to prepare the people who will be interviewing candidates How to expose skill sets during the interview How to regroup after the interview Why candidates that don’t meet a checklist are sometimes still hired How to set expectations with candidates when your company is going through a period of change How expectations and the role are different when you are the first product manager on a team -- Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA. -- # How to Interview Product Managers Transcript   Poornima Vijayashanker:         In the last episode of *Build*, we talked about the various personas when it comes to the product manager role and how to go about sourcing candidates. If you missed that episode, I've included a link to it below. Next you're probably thinking given how nuanced the product manager role is, how do you go about actually interviewing and making sure they have the right skill set?   Poornima Vijayashanker:         Often this can cause the interview process to become really fragmented. You start to see some interviews that are very technical, others that try to expose business skills, and a third set that might just involve mostly soft skills. If you don't have that right set of criteria or practices, some of the best candidates can just fall through the pipeline. In today's episode, we're going to expose some of those best practices, stick around.   Poornima Vijayashanker:         Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host Poornima Vijayashanker. In each episode, innovators and I debunk a number of myths and misconceptions related to building products, companies and your career in tech. We've been talking about the product manager role, how nuanced it is, how to source candidates and also, how to go about interviewing. Given how nuanced it can be, it's a challenge to set objective interview criteria as well as consistent practices to expose the skills that you need for your company and for your team.   Poornima Vijayashanker:         But fear not, because in today's episode, we're going to share some of the objective criteria and some best practices that you can adopt for your interviews. To help us out, Jeana Alayaay is back. You'll recall that Jeana leads the product management and design for Pivotal's IT group. Thanks for joining us again.   Jeana Alayaay:      Thanks for having me again.   Poornima Vijayashanker:         Yeah. I've got to admit that I've gone through a number of product management interviews myself. After spending countless hours doing interview questions related to technical skills, business skills and then having done the work of actually leading teams, building products and shipping them, I was surprised by the feedback that I got from some of the interviewers saying I needed to do even more to get the role.   Poornima Vijayashanker:         Why does this happen? It makes people feel like maybe you just need to answer the questions a certain way to get through the interviews so it’s like taking a test instead of knowing the information.   Jeana Alayaay:      I think there's three things here. I think one, there's a total disconnect between the job postings and what a company is actually looking for. I think the way that I've thought about it is, a job posting is actually part of the company's larger marketing collateral. So, you're not actually going to get the real deal on culture. This thing, it's never going to say like, "Hey, looking for a PM to walk into a super hostile environment." It's never going to say that.   Jeana Alayaay:      And so, I don't know that we can change that bit. But, I think what we can say is like, OK, where's the next touchpoint with the candidate? And it's with recruiting right? I think doing a lot of upfront work with recruiting sort of improves this, but I'm jumping a little bit ahead here.   Jeana Alayaay:      I think the second problem is that the hiring group itself isn't actually aligned on what sort of profiles they're looking for. You have anywhere from two to nine interviewers who are going in interviewing the candidate, they get to the end of the process, pull together all that data and you can't actually agree on whether or not to hire the person because no one ever said, "This is what a good candidate looks like." Or even better, "This is what a bad candidate looks like." As we all know, sometimes it's hard to know what good looks like, but we can definitely say what bad looks like or, this isn't going to fit.   Jeana Alayaay:      I think the third related thing is that the interview process most often doesn't actually resemble the environment that the candidate would actually be walking into should they get the job. A lot of companies have this prisoner's dilemma process where you go from person, to person, to person, to person and they ask you...Sometimes it's on script, sometimes they have their own scripts, but that doesn't actually resemble a product manager's job of doing a lot of work in groups, going around getting alignment like a lot of collaboration.   Jeana Alayaay:      I just don't think it resembles the environment at all. And so again, they get to that end of the process and they say no because they don't think the candidate's going to be successful in the environment but they've never actually given the candidate the chance to demonstrate whether they would be because it doesn't look anything like that.   Poornima Vijayashanker:         So then how do you get that criteria or how do you build that into the interview process?   Jeana Alayaay:      I think in general we don't put enough time into hiring. We put a lot of focus on the hiring manager, but we don't talk about the other interviewers. Everything from like, what is the group looking for to, are the interviewers themselves actually prepared to interview? I've come across these interesting situations where the interview process for one company or another posted on Glassdoor and that team says, "We've got to change the interview process because the candidate will know what to say."   Jeana Alayaay:      I go, "Well, do you actually know what questions to ask to get at that data outside of following the script? Do you know in your gut what you're looking for? What the company is looking for? Can you ask that question 10 different ways?" We don't often talk about whether the interviewers themselves are actually prepped to do this work.   Poornima Vijayashanker:         Totally, there is such a thing as a bad interviewer.   Jeana Alayaay:      Yeah, absolutely and so you end up with like again, two to nine people who are doing totally different things and none of that's really giving you a clear signal about whether or not this person is going to be successful in this company.   Poornima Vijayashanker:         Yeah. How do you then prep the interviewers and then convey the criteria back to the candidate?   Jeana Alayaay:      Two part here. I think one is, you actually need to train interviewers. At least on my team, I don't have folks interview who don't have experience interviewing. So, they should actually have to shadow other folks, cross-discipline and within discipline that have interviewed before and actually understand what that process should look like. And, understand from the hiring manager what they're looking for.   Jeana Alayaay:      Sending somebody in cold no matter what level they're at, you're not going to get the best outcome out of that. I think going back to the recruiting process, I think it's totally fine and good to tell the recruiter to tell the candidate, "Here's what they're looking for." And I thi

To build a product, you need a team of engineers, designers, and the glue that keeps them together: product managers!   The role of the product manager has dramatically changed over the past decade, and because it’s still a relatively new field that’s in flux, companies often struggle to find candidates, which in turn makes it hard for candidates to understand what companies are looking for.   So all this month, we’re going to focus on a number of best practices for sourcing, hiring, interviewing, and retaining product managers.   In today’s episode, we’ll focus on giving you a lay of the land, starting with how product management is evolving and how to go about sourcing candidates for a product manager position at your company.   To help us out, I’ve invited Jeana Alayaay, the Director of Internal Products and Services at Pivotal.   This episode is chock full of helpful best practices for both product managers and those looking to hire them. As you watch, you’ll learn the following: How product management has evolved over the years Why you need to think about the type of product manager you are looking for (hint: there is more than one persona!) How to communicate the key criteria you are looking for in a candidate How to build a pipeline of candidates How to train recruiters to help screen candidates How to stop hiring out of desperation Why it’s actually helpful to give candidates a quick no -- Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA. -- ## How to Hire Product Managers Transcript   Poornima Vijayashanker:        I know I'd love to just wave a magic wand and find top technical talent. But I've learned over the years that it takes a lot of effort to source, interview, hire, and retain that talent. It's become even more challenging in a new field like product management where company criteria changes as well as the skill sets that candidates have. So if you're struggling to find those product managers that are going to be the right fit for your company, stay tuned because we'll share a number of best practices in today's episode on sourcing candidates.   Poornima Vijayashanker:        Welcome to *Build*, brought to you by PivotalTracker. I'm your host, Poornima Vijayashanker. In each episode of *Build*, innovators and I debunk a number of myths and misconceptions related to building products, companies and your career in tech. When you got a lot going on it's very tempting to want to take short cuts to hire candidates. But those shortcuts can often backfire causing you to hire somebody that may not be a good fit for your team. And when it comes to a role like a product manager where they're going to be interfacing with a lot of different people as well as teams, you want to make sure you got the right fit and you may need to put in a little extra effort to make sure you get that candidate.   ## Best practices for sourcing product managers   Poornima Vijayashanker:        In today's episode, we're going to talk about some best practices when it comes to sourcing product managers as candidates for your company. And to help us out I've invited Jeana Alayaay, who leads product management and design for Pivotal in their IT group. Thanks for joining us today, Jeana.   Jeana Alayaay:       Thanks, Poornima.   Poornima Vijayashanker:        Yeah.   Jeana Alayaay:       Good to chat with you.   ## The evolution of product management and the role of the product manager   Poornima Vijayashanker:        Thank you. So you've been a product manager for quite a while now and you've seen it evolve as a role, so walk us through the evolution that you've seen and why it's come about?   Jeana Alayaay:       Yeah, so I think to answer your question about how product management has changed, think about how the market's changed. So there's a lot of touch points with technology and consumers and businesses and so the expectations for what quality and user experience look like are increasing, increasing, increasing. So in order to accomplish that like product teams have to do a lot of cross-discipline collaboration in order to create and maintain that experience. It's actually this one big people problem. One of the main jobs of product management is really to manage that people problem. So the folks who are both good at that and who want to do that work are really sought after.   Jeana Alayaay:       Before, when we think about product management we think more about project management which is like who's managing deliver in the backlog. And now we're thinking more about like who's managing people ecosystems within a product organization?   Poornima Vijayashanker:        OK. So that means inside of the company, not people as in users.   Jeana Alayaay:       Yeah.   ## Types of product managers   Poornima Vijayashanker:        OK. Now you and I both know there's also a lot of personas out there when it comes to product managers. There's the growth hacker, the workflow warrior, the community, the creator or connector and then somebody that manages platform, data or just mobile. Do we need all these personas? What's kind of the...Are there a lot of differences and nuances between them?   Jeana Alayaay:       Yeah. That's a great question. I love personas because it gives you a sense of who to look for out in the wild but I don't know that a persona is going to solve the problem of the modern product. So I think what we're looking at is products are these big spaces now. They're multi-part, they're multi-platform. They have a lot of different pieces and components themselves can be considered to be products. When you're thinking about managing that you should really be thinking about managing a team. Not having specific people on specific verticals and I'll tell you why.   Jeana Alayaay:       So when you hire specific people on specific verticals what you get is a bunch of individual contributors doing their own thing and that team is unable to elevate the bigger product or offering right at the higher level. So you just sort of miss the mark on that I think.   Poornima Vijayashanker:        Got it. OK so kind of keep the skillset in mind for each of these but think a little bit more higher level.   Jeana Alayaay:       Yeah.   ## Take stock of the skill set you need from a product manager for the long term   Poornima Vijayashanker:        Now this is the second PM team that you're managing and building at Pivotal. What did you learn from your first experience that you're applying now?   Jeana Alayaay:       Yeah, so I think the thing that I was talking about earlier was really think about the makeup of the team like the skillset, and figure out how to compliment the skillset and build it out very intentionally. So I think when I first started as a hiring manager so to speak or a team leader, practice manager, I thought, "Yeah I'm going to hire a person to do this and hire a person to do that and hire a person to do that." But the job itself is so cross-functional that no one actually really works in isolation. So really you need a bunch of people who can pair up and actually combine skills in different scenarios.   Jeana Alayaay:       And so thinking about that, I think OK what do I need in three months, what do I need in a year? What should this team look like, rather than what do I need now. And I think that's counterintuitive because by the time you have a wreck open there's a little bit of desperation there because you need somebody to cut wood in hot water. You can fall into the trap of hiring somebody that you need today but not necessarily the person you need tomorrow, if that makes sense.   ## How to uncover and communicate the key criteria you’re looking for in a product manager   Poornima Vijayashanker:        Right, especially if your product evolves or the strategy evolves or if the market evolves as well. That's actually a great segue into my next question which we got engineering, that's become very nuanced. There's front end there's back end and then there's specialization within that for the same kind of thing with a product manager, how do I determine my needs and set up the sourcing criteria for my team?   Jeana Alayaay:       Yeah, that's a good question. I think the best thing to do is actually look to your team for that information. So I think as hiring managers, we're sort of set up into the system to make the decision in isolation but I think you can't actually know all the things that your team is experiencing on the day to day. So having your team do that gap analysis is really important. And having explicit conversations about what's working, what's not working, were we missing. Were you missing the mark? What kind of people do we need? Having that conversation is super important because I don't know that it is most that...Sorry let me back up. Most of the time the problem is not actually hard skills so to speak it's hard and soft skills. And so the thing that your team is missing is not somebody who can do really awesome data analysis or code or whatever, it's usually who's going to manage the most hostile, fiscal stakeholder group that you can think of.   Poornima Vijayashanker:        So what are those conversations look like or how do you bubble that criteria up?   Jeana Alayaay:       Yeah, so I think my team prefers more structure so we usually actually do a work session where we sort of dump and sort what those needs are, what problems we're solving for. And really what I think my job is is to make sure that we're looking, again, three months, six months, a year, even two years out and we're not just solving for we have a super painful thing right now but where's the team going? How do we see the organization's needs changing, how is the team going to have to shift its responsibilities to meet those needs? And have that be a very, very explicit conversation.   ## How to source product managers   Poornima Vijayashank