Build

It’s the start of a new year, which is an exciting time all around. You’re probably excited about new opportunities, starting a company, or building product in 2018!   While I’m all for optimism, I’ve also gotta stay true to them theme of Build: debunking myths and misconceptions when it comes to building tech product, companies and your career in tech ;)   So we’re going to spend the next four episodes of Build debunking themes around fundraising for startups.   I know what you’re thinking: “Poornima, is this really necessary?! Can’t we just focus on product and engineering? How about some Build Tips with those friendly product managers, designers, and engineers from Pivotal Labs?”   Don’t worry we’ve got plenty of those in store for you! Before we dive back into the fun and friendly banter of Ronan and his team, I thought it was necessary to start 2018 debunking myths around fundraising.   Here are my reasons for doing this:   Reason #1: If you want to be a founder and start a startup in 2018, you need to k

I don’t know about you, but I cringe at the thought of having to commute. The traffic, road rage, not to mention having to find parking… it was enough to make me throw in the towel 7 years ago!   Since then I have been managing remote teams around the world, and as I continue to scale my team I learn best practices from companies who have been doing it for longer than I have like Olark.   But, I know there are a lot of people out there who just don’t know if they can do it.   Maybe you’re one of them. You worry if you’ll be productive, able to communicate effectively and fit into the company culture.   One of my employees, Meghan Burgain felt the same way about a year ago. She had a number of reservations having never worked remotely before.   In today’s Build episode, Meghan and I are going to dive into some of these reservations, how you can get over them, and of course the wonderful benefits aside from working in your jammies ;)   You’ll learn:   The tools and processes to use to stay productive and on t

Did you share last week’s Build episode on product design sprints with your teammates?   Wait! Give me two chances to guess what the outcome was...   … you did and you faced some pushback? Well, kudos to you for putting it out there!   … or maybe you didn’t because you were afraid of the pushback you’d get? That is OK too!   Charbel Semaan and I are back this week and prepared to help you get over the pushback you received or will receive once you bring up the idea of product design sprints to your teammates.   You’ll recall Charbel Semaan has been a product designer for the last 20 years and recently launched his brand, Made in Public.   Charbel and I have built a lot of products, and we know that even if our teammates hate the current process and the outcomes it produces, they will still find comfort in it and resist adopting a new one because there’s a lot of fear when it comes to change.   But no one is going to willingly admit to being scared, so they’re going to couch their fear in remarks that are skep

How many times have you and your team spent countless hours building, bug fixing, finally releasing a new feature only to hear feedback from a customer that it’s not what they wanted?   Or worse, they don’t say anything…   Why?   Because they aren’t even using the new feature!   Back to the drawing board…   Yet again it again takes weeks or months to build and tweak and nothing changes. You just keep missing the target, asking for more time, money, and resources.   But it doesn’t help, and people just end up burning out building the wrong thing.   What if I told you that the problem in your product development process is that you are spending too much time, money, and resources and need to cut back?   OK, I’ll give you a minute to shake your head at me...   Sometimes when we have too much it causes us to go in a lot of different directions. Or worse no direction at all because we’re stuck in a decision deadlock!   We lose sight of our customers and end up building just for the sake of building, thinking that

Transcript for What Is Product Debt And Why You Need To Prioritize Paying It Down   Poornima Vijayashanker: Did you recently show your designs to an engineer and hear this?   Ronan Dunlop:       It is going to be challenging to implement in time for the next release.   Poornima Vijayashanker: Why?   Ronan Dunlop:       They're pretty complex.   Poornima Vijayashanker: Why are they complex?   Ronan Dunlop:       This slider alone is new functionality that is going to take at least two days’ worth of time to implement on the front end, maybe more.   Poornima Vijayashanker: OK, what else?   Ronan Dunlop:       To do these visualizations we're going to need to pull in a lot of data, and that's going to slow down the performance of the app. Some of these new workflows require changes to our current APIs, which have already accrued a significant amount of tech debt.   Poornima Vijayashanker: OK.   Ronan Dunlop:       It doesn't seem doable for the upcoming release. I'd recommend changing the designs.   Poornima Vij

Transcript for Should You Worry About Your Skills Getting Rusty?   Poornima Vijayashanker: In the last episode, we talked about what it's like to transition from being an individual contributor into a leader, and explored some tradeoffs. If you missed the episode, be sure to check it out in the link below this video. In today's episode, we're gonna talk about one of the major concerns people have that holds them back from doing the transition, which is the concern that their skills are gonna get rusty. So, stay tuned.              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. One myth that often holds us back from transitioning from being that individual contributor into a leader is the fear that we're gonna get rusty when it comes to the skills that we've worked painstakingly hard to craft. If you're an engineer, you're

Have you been in your current role for a while, and are eager to try something new?   Perhaps you’ve thought about transitioning from being an individual contributor into a leadership role, but you’re not sure if it’s the right move for you?   You worry about being qualified enough, leading people, being an authority figure, and what your day-to-day will be like.   While it sounds exciting and maybe a great opportunity to grow, you worry about your existing skills getting rusty.   Well, all this month on Build we’re going to be exploring the tradeoffs that aren’t talked about when we choose to transition from being an individual contributor to a leader. In today’s episode, I’ve invited Jean Hsu who was formerly an Engineering Manager at Medium and is now an Engineering Leadership Coach.   Here’s what you’ll learn in this episode:   Why our perception of who or what we think it takes to be in a role is often wrong, and why we are more capable of learning and growing in a new role than we realize When it comes

A redesign is a great way to reinvent your brand, get a leg up on the competition, and revisit those clunky and outdated workflows.   While we may be eager to jump right in, we have to be careful about what is actually going to help us accomplish our business goals.   In today’s Build Tip, I’m joined by Leslie Yang who is a Senior Product Designer at Pivotal Labs. Leslie and I are going to talk about how much to include in a redesign and what you need to do before you start a redesign.   You’ll learn:   The hidden risks of jumping into a redesign and how to avoid them What happens when we redesign too many pieces of the product The type of metrics you need to be tracking for each piece of the product you redesign   Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA. -- Transcript for Product Re-design: What To Do Before You Redesign Your Product   Ronan: I'm not sure about this, Poornima.   Poornima: What? What? What's going on?   Ron

All this month on Build, we’ve been talking about project management. First, we shared two ground rules you need to set for yourself to get through a software project successfully, and in the last episode, we shared strategies for handling new ideas and unexpected challenges that may derail your project.   But you’re probably left wondering, what do you do to get through the last 20% of a project? Especially when the deadline changes, and it’s clear that teammates are starting to burn out and become demotivated? Is it even possible to get through it and successfully ship?   And if you are able to get through those hurdles and successfully ship, what next?   In today’s Build episode, Jen Leech who is the VP of Engineering at Truss, and I are going to share proven strategies to get you through that last 20% and successfully ship!   You’ll learn:   - Why the last 20% of a project is really a lie! - How to avoid the complacency that comes with a deadline that are very far away in the future. - What to do when the

In the last Build episode, we talked shared two ground rules you need to set for yourself to get through a software project successfully. But we know that managing our own anxieties is only half the battle to keeping the project on course, the other is navigating new ideas or unanticipated challenges.   Many of our teammates have ideas and solutions that can help. They are eager to have their ideas heard, so they speak up. While others are shy and worried about speaking up. But their insights and ideas can save the project!   As the project lead you know it’s important to hear your teammates out to uncover challenges early on and prevent them from derailing your progress. But how do you encourage and instill confidence in the introverted ones, and is there ever a point where you can stop entertaining new ideas and start building? -- Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA. --  ##Project Management: How to Respond to New Idea

So you got tasked with managing your first high-stakes software project? Like handling tech debt, breaking up a monolithic code base into a microservices architecture, or something else?   Congratulations!   Are you excited?   Maybe a little nervous?   Or maybe you’re really nervous because you need to deliver on a tight deadline, and there is a lot on the line like your relationship with customers, revenue, and most importantly your job!   Fear not because all this month on *Build*, we’re going to be tackling the topic of how to manage your first high-stakes software project.   In today’s episode, I’m joined by Jen Leech who is a VP of Engineering at Truss. Jen and I dig into some valuable strategies that will address and alleviate your anxieties around managing your first high-stakes software project.   Here’s what you’ll learn in this episode:   Two valuable rules that will save you from concocting stories and creating unnecessary drama around a project. How to prevent ideas from being shot down instantly

As if preparing and delivering a presentation to your peers isn’t nerve-wracking enough… you also have to worry about the Q&A period at the end of your talk!   You’re worried about people asking not one but TWO questions! Having to decipher those questions that are really just comments. Then there is THE dreaded question: the question you don’t know the answer to.   You don’t want to appear stupid in front of your audience!   Truth is that the Q&A period can leave many first-time public speakers feeling like they need to know everything before they give a talk!   But you don’t, and we’re going to debunk this myth and more in today’s Build Tip.   I’m joined by Lara Hogan who is the VP of Engineering at Kickstarter and Author of Demystifying Public Speaking. Together we’ll be sharing a number of strategies to help you get ready for ANY question you receive during your next Q&A session after a presentation or team meeting. You’ll also learn some techniques to calm your nerves, engage your audience,

All this month we’ve been focused on the theme of pitching. We started out by talking about why many creative problem solvers shy away from pitching, leaving it up to CEOs, founders, and sales people. But, pitching is a really valuable skill that all of us need to hone in order for people hear us out, adopt our ideas, and believe in our solutions.   To help you embrace pitching, we shared the most common mistakes people make when pitching and how to overcome them. Then mentioned that the most effective and authentic pitches boil down to a powerful technique many of already do every day, storytelling. We covered why storytelling is powerful, how to condense a story down, and weave in our credibility.   By now you hopefully understand the importance of pitching, but you might be worried about having to pitch different audiences, and what to do in a setting where you only have 5 minutes or as much as 50 minutes to pitch.   Don’t worry Marie Perruchet and I have you covered! In this final segment on pitching, we’

One of the reasons people don’t like pitching is because they feel like they have to be someone else. They have to abandon their personality, get into character, and speak in a way they normally wouldn’t in order to impress a colleague, customer, or investor.   However, people on the receiving end of the pitch are going to see through and disengage quickly. A sales-y pitch is one that isn’t rehearsed and the person pitching hasn’t taken the time to figure out how to engage their audience.   What we don’t realize is that we don’t need to change who we are or how we speak to engage audiences. Many of us are already practicing a powerful pitching technique in our everyday lives, storytelling. And when we deliver stories in a conversational approach we come off as clear and authentic.   But we may still be opposed to starting a pitch with a story. We worry about it being too long or short, and the theme and details resonating with the audience.   Well in today’s Build episode, Marie Perruchet author of One Perfe

Have you ever had an idea for something, like a process or product that you wanted to improve? But instead of sharing your idea with others like your friends or co-workers, you just kept it to yourself because the thought of having to “pitch it” felt icky and salesy? Many of us who are creative problem solvers feel this way. Since pitching doesn’t come naturally to us, we just leave it up to CEOs, founders, and sales people. However, pitching is a really valuable skill that all of us need to hone, because only if we pitch our ideas will people hear us out, adopt them, and believe in our solutions. In today’s episode of Build, we’re going to tackle a number of misconceptions people have about pitching as well as the common mistakes people make while delivering them. In future episodes, we’ll talk about how you can pitch in a way that resonates with your personality and the various types of pitches you need to prepare because it turns out that an elevator pitch isn’t enough! To help us out, I've invited Marie P

Every product release our goals are the same: we want to show customers we care about meeting their needs and we want to stay ahead of our competition! So how do we get it all done? We cram as many features and bugs as we can think of. Cutting back is for complainers!   Is it really?   Or… is it hard to estimate how long a feature is going to take to build and a bug to fix? And by not cutting back are we jeopardizing the quality of the product we release and sacrificing the sanity of the team?   We get that this is an age old struggle. It’s hard to challenge business goals, and start a conversation within your team about why you aren’t going to do something without being seen as a slacker.   If you or your team has struggled to figure out what will produce quick wins, what to ignore because there is no value, and what may be too complex to pursue in a single release then you’ll want to watch today’s episode! In today’s Build Tip you’ll learn:   Why people choose to cram versus cut back Why it’s hard to estim

All this month, Joy Dixon and I have been digging into the theme of working on side projects that you’re passionate about. We started out by talking about how to keep your day job and pursue your passion project on the side, and last week we talked about how to keep your passion project moving along when you physically can’t.   In today’s final episode, on side projects for this month, we’re going to talk about how to keep your passion project growing despite challenges.   When we’re just getting started all the passion we have for our side project makes us feel like we can tackle small challenges that come up every day. But over time we start to uncover bigger challenges like funding, dealing with regulations, lacking experience, and missing self-imposed deadlines and milestones.   When we hit one of these challenges we feel stuck. Our side project stops growing, and again we’re tempted to quit.   Instead of giving up, it might be time to re-evaluate the direction and purpose of our side project.   In today’

In last week’s episode of Build, we began exploring the theme of pursuing a side project while keeping your day job. Jox Dixon and I did some myth busting around the need to go all-in. If you missed the episode you can check it out here.   This week we’ve got a pretty meaty episode for you. We’re going to dive deeper into this theme, and talk about what to do when the inevitable happens: you can’t physically work on your side project.   We thought it was particularly important to tackle this topic because it’s happened to both Joy and myself more than once, and it’s probably already happened to you or you’re thinking about how to handle it when it does.   The common culprits that hold you back from physically working on your side project are burnout and stress. Each is often prompted by teammates at your day job needing you more, you feeling the need to do everything yourself, and not having enough help on your side project or feeling like you can’t ask for help!   People often think it’s the quality of the i

It’s a brand new month, and we’ve got a new theme we’ll be tackling on our show Build! We’re going to be talking about building, managing, and growing a side project you are passionate about while keeping your day job. I’m sure you’re aware of all the benefits that come with a side project: you get the chance to explore and learn new skills. And if it’s 100% yours, you get full creative freedom. However, you’ve probably heard that once your side project starts to grow you need to make a decision… You need to decide to go ALL-IN! You need to quit your day job and pursue that side project. Otherwise, you’re not really passionate about your idea, you’re not committed, and chances are you’ll appear less than focused! But going all-in on a side project can be a real challenge for many of us that don’t have the means, really like our day jobs, and truly want to have something on the side. Well, it turns out you don’t actually have to go all-in, and in today’s episode we’re going to tackle this myth. In future episo

What Is Tech Debt And How Do You Manage It It’s crunch time! You’ve got eager customers who are waiting for you to ship product, your teammates are eager to complete the release and move on, and you don’t want to be the bottleneck. So what to do you? You rush through writing your code and put in a quick fix. It’s good enough to pass tests and a quick code review. Unfortunately, crunch time doesn’t come around once in a blue moon. It happens more often than we’d like. And sadly it gets heralded by sayings like: “Move fast!” “Break things!” And, “Ship code!” As designers, product managers, and developers we are eager to share what we’ve built with customers. However, constantly operating by the seat of our pants comes at a price and that price is tech debt. Whether you have or haven’t heard of tech debt, I’m pretty sure you’ve experienced its effects. If you’ve been on product teams that seems to constantly be putting out fires, you’ve probably noticed that over time all those quick fixes add up. And when it co