<p>Today we're talking to Gaurav Chandrashekar, a PM at PayPal with a ton of international experience at places like Spotify and Grab. Gaurav talks about his career journey as a PM, how to make big career decisions, and how to maintain a sense of wellbeing and motivation.</p><p><img class="image_resized" style="width:75%;" src="https://inputwebsite.s3.us-west-2.amazonaws.com/library/Gaurav_Long_f2f59ef429.jpg" alt="Gaurav_Long.jpg" srcset="https://inputwebsite.s3.us-west-2.amazonaws.com/library/thumbnail_Gaurav_Long_f2f59ef429.jpg 202w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/small_Gaurav_Long_f2f59ef429.jpg 500w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/medium_Gaurav_Long_f2f59ef429.jpg 750w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/large_Gaurav_Long_f2f59ef429.jpg 1000w," sizes="100vw"></p><h2>Thanks for joining us, Gaurav! It’s nice to connect. First up, can you tell us more about what you do at PayPal?</h2><p>Sure! Long story short, I’m currently a PM at PayPal. I work on the banking partnership and payment experience team. I’m responsible for one of the ‘Add Card’ flows in the app, which is where users can link their cards by directly connecting their PayPal account to their bank (e.g. Bank of America, Chase Capital One, and so on).</p><p>From a user’s point of view, they’re looking to make a transaction — buying something with PayPal at checkout, making an in-store transaction by scanning with a QR code, or even paying with the cards in their wallet. Our core focus is to make sure nobody drops off when they have an intent to purchase.</p><h2>Nice! How did you come to be in that role? What was your background, pre-PayPal?</h2><p>Well, after I graduated I worked at Spotify for awhile. This was back in 2011, when it was still just based in Sweden. I learned from some amazing technologists there about how to build great software. It was really eye-opening, and I realized that you can have this global impact by building fantastic software and focusing a lot on the user experience.</p><p>I was really excited about entrepreneurship, so next I joined a startup with a couple of ex-Spotifyers who were focused on visual search. We didn’t achieve product market fit, but we moved to the US, and that was my introduction to North America and to Silicon Valley.</p><p>I was an engineer all through this time, and the startup experience taught me a lot. I was excited about technology, and as an engineer was thinking a lot about “okay, how do I build this?” I thought, if you build it, they will come. But I learned the hard way that this isn’t the case, after building things nobody used.</p><p>Next I wanted to think more about what problem was actually the right one to be solving. It sounds like an easy question to ask, but it takes a lot of effort and thought to really nail it. (I’ve learned a lot from people who focus on questions like this — folks like <a href="https://twitter.com/shreyas">Shreyas Doshi</a> and <a href="https://twitter.com/cagan">Marty Cagan</a>.)</p><p>From there, I wanted to pick a place a little more long term, so I ended up choosing Singapore. It’s nice to be closer to family, and there are some amazing companies in the region. I joined Grab as a PM — it’s like Uber, in this part of the world. And then from there I ended up at PayPal. I love the global atmosphere at PayPal.</p><h2>Awesome, you’ve lived in a lot of places. That’s a real series of adventures. What was the process like that allowed you to build your career at these different companies? And how did you make the decision to move from one to the next?</h2><p>Great question. Earlier on, I was evaluating opportunities based on, “is this someone I’d love to work with as a manager, a teammate, a collaborator a colleague? Will this be something I’ll be excited to wake up every day and work on?” It was that simple. I also started thinking, “do I get to explore a different culture, a different country, a different way of life?” So that sense of exploration led me to Sweden, and New York, and Latin America.</p><p>And eventually, after building up a little experience, I was also asking myself, “is this is the kind role I can excel in? Is this where I want to spend time and grow my career?” Long term, I want to be somewhere that can demonstrate value as a business, and for customers. That makes it sustainable.</p><p>You can also join a startup, which is a little high risk because often you’re still trying to figure out the answers to those questions.</p><p>So that’s the framework I was thinking about, at a high level.</p><p>Ultimately it comes down to, which location, what stage of company, what kind of manager and culture do you want to be working with? And of course, compensation.</p><p>I built a <a href="https://www.evernote.com/shard/s18/client/snv?noteGuid=50bcc2bf-ad67-4d45-9a4e-900c482ae33f&amp;noteKey=9b0a9d926b654cdf17013b12f9ef582f&amp;sn=https://www.evernote.com/shard/s18/sh/50bcc2bf-ad67-4d45-9a4e-900c482ae33f/9b0a9d926b654cdf17013b12f9ef582f&amp;title=Career+decision+framework">career decision framework for myself</a>, which I’ve shared with some friends and am happy to share here too.</p><h2>That’s super helpful! So having lived and worked in so many different countries, you must have experienced a bunch of different business cultures, as well as differences company to company. Is there anything you’ve learned from these different business cultures that has been really helpful to you, or made you see things differently?</h2><p>That’s a great question. I haven’t thought a ton about it, but one thing that stands out is that, having spent a couple of years in Sweden, I love the way they work for three reasons. One, they think about building technology in a long term way. You can see that from the likes of Spotify, iZettle (which is part of PayPal), Klarna, Skype, and so on. They had broadband internet pretty early on, which I think gave them a leg up when it comes to technology innovation.</p><p>The second thing is that they have a very good social safety net, so if you take a risk and it doesn’t work out, you’ll have support from the government, to some extent. It gives people more freedom to do whatever they want. They’re not as worried about, “oh no, I have to pay these bills right away, I can’t afford to focus on my creative pursuits.” And that’s a bit of a luxury. Maybe people can’t imagine the value that different systems of government can give you. So I think that’s something really beautiful.</p><p>And the third thing is, they really value work-life balance. I think that supports the mindset where they build things for the longer term — it’s not just about rushing to get things out in the next six weeks or for the next quarter. Instead, they’re really thinking through some of the bigger decisions and the impact those will have. So those things were really eye-opening for me in Sweden.</p><p>All that said, I find the common elements still remain the same from place to place at different technology companies, working in a very globalized environment. I don’t see very many differences in terms of processes and principles from one company to the next.</p><p>Personally, I seem to gel more with cultures that are global. At PayPal we have a pretty global team, that values diversity and inclusion, and I feel at home.</p><h2>PayPal is such a big organization, how do that manage working as a global team?</h2><p>Well, first of all, PayPal has been around for more than two decades. I’ve heard that some of the code that Max Levchin wrote 20 years ago still runs in production, which is amazing. What that means, I think, is that the culture has developed to think globally about platforms from the get go. It’s never a question of, “hey, can we launch this in Germany or Spain, immediately?” Instead, we think, “okay, if we do this, how would it impact the US, or Brazil, if we launched it in those countries?” And what’s cool about this is that often these questions come from engineering. They can see the truth in the code, and they know they’ll have to figure out what changes need to be made.</p><p>As a PM, it makes me really think on my feet, and think far ahead. The fact that we’ve built the systems over decades to think in this way — by default, thinking globally — allows us to have a big impact.</p><p>Some of it is changing, too. I sit in Singapore, and the development centre here was opened eight plus years ago. The team has been growing. In part, it’s an initiative to help make us available in different time zones, and not just focus our efforts in the US (although of course the US is one of our major markets).</p><p>But if you think about where we have to go next, where our next billion users will come from, they’re not going to be in the US or even in Europe. So there’s been a lot of focus on rapidly emerging markets, including APAC.</p><h2>How big is the product team at PayPal?</h2><p>Good question. PayPal has a slew of product groups, including Crypto, Installments, and Credit, as well as others like BrainTree, IZettle, and Venmo that are also part of the group. I wouldn't be surprised if our core PM community internally is in the hundreds.</p><h2>Do you find the function really different being part of such a large product team, as opposed to be on a small startup team?</h2><p>It’s great that bring that up. My early experiences at startups were as an engineer. And I realized that I wanted to learn fundamental principles of product market fit, like, “how do you do user research? How do you synthesize it? What are the right questions to ask? What products should you build?”</p><p>And there are two ways you can really learn that. One is by joining a company that maybe seems to have product market fit, but it’s still unclear if it’s sustainable. It could be a startup or scale-up that’s taking off globally.</p><p>The other way is to join an established company with proven product market fit, where the question is more about what kinds of enhancements you can make, and what new products you can build on top of the existing ones, with the distribution channels and customers you already have.</p><p>Having spent time at scale-ups and now at PayPal, it’s clear to me that the principles of “how to build a product” don’t change. You ask the same questions, it’s just the mechanics of how you translate that into execution that change. The speed you work at changes a little. But the principles remain the same.</p><h2>Absolutely. You started out as an engineer. Obviously many PMs come from an engineering background, and many don’t. If you were to offer advice to someone starting out, what would you tell them? Should they become an engineer first? How should they think about that question?</h2><p>Yeah, I get this question a lot, and there a couple of ways I think about it.</p><p>One thing I love is the creative aspect of coding. I still do it today, on side projects. Running a small app on the side, or coding something to automate one of your own work processes — it’s great to be able to do, and it’s something I hope to still be doing 10 years from now. It gives me a sense that I can create something with mown two hands.</p><p>On the other hand, it’s not something I’d like to do full time. Having made the mistake of building things nobody used, I realized the value of a PM — trying to understand the problem, figure out if there’s business value, figure out what’s feasible and viable.</p><p>For me, as much as I love to code and spend time thinking about systems, I also love the value of communication. One of my mentors early on said, “I notice you’re starting to think a lot about some product thinking principles, why don’t you start to take on some fo that work?” In a startup, that’s very easy to do because there’s always more work. So I started doing that.</p><p>The technical knowledge really helps. It gives me confidence that I know what I’m talking about. At PayPal I see a lot of people who are technical in nature, which is amazing, because conversations are really effective then. But it’s a double-edged sword. I often find that when I’m talking to engineers, it’s very easy to think about how we’ll build something, and forget about the customer. At some point you have to remove yourself from the equation and say, “hey, look, these are the user problems.”</p><p>So I try to keep a little distance — I leave it to the engineers to figure out how they’re going to do it. I can say, “here’s the problem that needs to be solved, but you guys figure it out.”</p><h2>What are some of the biggest challenges you’re facing in your role right now?</h2><p>Well, there are a lot of stakeholders at PayPal, and the complexity of getting sign-offs increases when you have a lot of processes in place. This is a function of big organizations, it’s not specific to PayPal. But understanding these processes takes awhile. I’m still relatively new, so it can be hard at times, especially if you have a startup mindset where you want to hustle to get things done. So, working with a long list of stakeholders, I try to focus on breaking things down into Step 1, Step 2, Step 3, and having patience.</p><p>The other challenge is my timezone. A lot of our stakeholders are in San Jose, which is great. It keeps me connected to what’s happening in the Mecca of tech, essentially. But it means I have to think ahead a lot. I don’t want to miss a day, so I have to plan, and work hard to keep close stakeholders aligned. I’m always trying to be better at building that working relationship across teams, and across different timezones and regions.</p><h2>And how do you approach that?</h2><p>One thing I do is keep a list of all my stakeholders, and I try to figure out what their communication style is. It’s not something they’ll always explicitly tell you, but it’s something you can learn for yourself. Do they respond on Slack? Are they more of an email person? Do they need nudges for you to get a response from them? So it’s just a model that you update as you continue to work with people, but it helps.</p><h2>On Twitter you talk a lot about your internal approach to work. How do you think about maintaining your motivation, your energy levels, and your work life balance?</h2><p>I started doodling recently and <a href="https://art.cggaurav.net/">putting these diagrams up on Twitter</a>, just about whatever I’m thinking about. It’s often to do with motivation, taking care of your mental health, productivity, and so on. It’s not specific to the PM role, but I think wellbeing is so important to take care of. Especially when there’s no differentiation between your work life and your personal life. I feel really privileged to be at a company like PayPal that really values wellbeing. It’s one of our core values. There are a lot of resources available to help you take care of yourself.</p><p>The other thing is, your ‘why’ can change. I’m always going back to, “why am I doing this role? Why am I at this company? What am I trying to achieve?”</p><p>For me, for instance, the common theme has always been that I really like working with the people I’m working with. Getting on calls energizes me. When I can solve a user problem, learn something new, launch something and start getting feedback, I really enjoy that process.</p><h2>Great framing! Do you have a favorite app or tool that you’re obsessed with right now?</h2><p>For me, it’s the Oura ring. It’s amazing. I love the app. I check it first thing every morning. It’s not because they have any new kinds of data. There are lots of fitness trackers out there. What they do really well is that package that content in a useful way. I love the user experience, and how they show you your scores. They also turn them into useful insights. They’ll say, “hey, did you drink alcohol yesterday that maybe affected your sleep?” Or “it seems like you’re sleeping later than usual, why don’t you prioritize your sleep today?” So the user experience, plus using the data to generate insights instead of just showing dashboards — it’s really cool.</p><h2>I think you’ve convinced me to get one. Last but not least, have you read anything lately that you loved?</h2><p>I’m reading <a href="https://www.navalmanack.com/">The Almanack of Naval Ravikant</a>, by Eric Jorgensen. It’s amazing, it’s so succinct. I’ve followed Naval for awhile, but I love having this info in book form because I can read a little and let my mind wander and think about how I can apply it to my life, as opposed to just continuing to scroll on Twitter.</p><h2>Excellent recommendation. Thanks so much Gaurav, we really appreciate you taking the time!</h2><p>For more from Gaurav, <a href="https://twitter.com/cggaurav">follow him on Twitter</a>, and check out his personal website, <a href="https://art.cggaurav.net/">Doodling between meetings</a>. Want more Product Thinking interviews? Drop your email in the newsletter box below.</p>

Output_Cover_Gaurav_b9de8e25e5.jpg

Output_Header_Gaurav.jpg

An interview with Gaurav Chandrashekar

<p>After countless hours of work and calendars filled with meetings, your app is ready to submit to the app stores. How will you get users to discover the product of your hard work and download it? App Store Optimization (ASO) and paid marketing are the keys to a successful launch.</p><p>ASO can be broken down into two main sections: keyword optimization and creative optimization. Paid marketing efforts include running ads from platforms that can not only help your new user downloads, but also offer organic coefficients. Using both of these strategies to their fullest potential will yield the highest results for your app launch and over time as your app matures.</p><h2>Keyword optimization</h2><p>Keyword optimization drives ASO visibility. You want users to be able to find your app organically by searching for a keyword, and seeing your app in the search results.</p><p>Keyword optimization is a crucial part of increasing organic discoverability. Selecting relevant keywords with high search volume before launch will help set your app up for success. If your app is ranked for these keywords, then your visibility will increase because more users will see your app in the search results.</p><p>When you deploy a new build, the store algorithms will begin to merchandise your app for roughly 3-4 weeks. During this process, the algorithms will scan the metadata for targeted keywords and possibly merchandise your app for additional rankings. Starting with strong optimized metadata helps Apple and Google easily understand your app from day one. Take note of which keywords or phrases perform the best using ASO software, and test them in your next build.</p><p>Optimizing your metadata can help your app rank for hundreds or even thousands of keywords and phrases, effectively expanding your overall organic presence. As you gain impressions and installs from these rankings, your app will build relevance in the eyes of the stores. This can, in turn, increase rankings -- which further expands visibility.</p><h2>Creative optimization</h2><p>Keyword discoverability will allow users looking to find an app like yours to discover it. But after a user sees your app, will they download it? Creative and conversion optimization drive the download part of your ASO strategy. All traffic eventually leads to your app store listing. Your on-page search and product page elements need to convince users to tap to get your app, and not a competitor’s.</p><p>A picture may be worth a thousand words, but effective app store creative can be worth thousands of installs.</p><p>Optimizing your creative assets will improve your conversion rate, maximizing the impact of your increased keyword visibility. Increasing your conversion rate can help your app climb up the ladder of keyword rankings, because app stores take conversion into account.</p><p>When working on creative, start by implementing best practices to improve relevance with your target audience and increase conversion. For example: highlight key features in the screenshot copy or in-app UI. Users are more inclined to install an app if they immediately recognize their search queries, whether it's through keywords or in-app imagery.</p><p>A/B testing tools are also important for optimizing your metadata and creative. Testing gives you quantifiable data to understand which aspects perform the best. You can test various aspects, like which colors convert the best, or which keywords to highlight. From there you can build upon the success of previous builds to continually improve performance.</p><h2>Paid marketing</h2><p>New apps will get little organic traffic because they don't have high rankings for high volume keywords -- it takes time to build relevance for the algorithm. This makes it hard for users to find a new app, without a little help.</p><p>This is where paid marketing comes in.</p><p>Paid marketing from healthy channels, like Apple Search Ads, Google Ads, or Facebook Ads, will increase the volume of traffic to your app store listing, and help stimulate the store’s algorithm to index your listing at a faster rate. This has three benefits:</p><ul><li>Improve organic keyword ranking visibility</li><li>Increase your user base at a quicker pace</li><li>Test asset performance</li></ul><p>Paid traffic is different from organic, because you're directly bidding for placements that can appear either above, or entirely outside of, organic search results. These paid placements can be at the top of the search results for Apple Search Ads, or a banner on a YouTube video for Google Ads. As your listing gains installs, you become more relevant in the eyes of the store, potentially increasing overall organic rankings.</p><p>Each paid channel has unique pros, cons, and a different level of influence on organic. For example, Apple Search Ads can have a direct impact on how your app ranks for keywords, and will display the screenshots already used in the App Store. Facebook Ads, on the other hand, will help with the overall volume of installs with an indirect impact on rankings. Facebook Ads also require creative assets made specifically for Facebook.</p><p>Start with the channel that best aligns with your marketing goals, budget, and team resources to help scale your user base. As your app usage and business grow, you can look into adding more channels to capture additional demographics.</p><p>ASO keyword and creative optimization together form an iterative process of research, testing/deployment, measurement, and improvement repeating. This cycle of continual improvement, paired with paid marketing to boost traffic, will set your app us for success.</p><p>Even if you've developed the best app ever, no one will know about it if they can't find it. ASO helps your organic visibility, by targeting relevant keywords and improving conversion performance with creative assets. Paid marketing supports your organic visibility, by driving additional traffic volume. Avoid a slow start after launch by using a combination of ASO and paid marketing strategies to get your app in front of the right users.</p><h2>About the author</h2><h3>Gummicube Co-Founder &amp; CEO, Dave Bell</h3><p><a href="https://www.gummicube.com/"><i>Gummicube</i></a><i> is a global leader in App Store Optimization with more than 11 years of experience optimizing and marketing apps. We offer the leading enterprise ASO technology and agency services, providing support to clients around the world. Our company is trusted by thousands of enterprise brands and leading startups including Microsoft, LinkedIn, Bethesda, SWEAT, GrubHub, McAfee and many others.</i></p>

Gummicube_blog_asset.png

Screen Shot 2022-11-02 at 2.35.28 PM.png

App Store Optimization tips for launch

<p>Today we chat with <a href="https://twitter.com/rishi_tripathy_?lang=en">Rishi Tripathy</a>, Chief of Staff at <a href="https://twitter.com/rishi_tripathy_?lang=en">On Deck</a>, a community where top talent come together to accelerate their ideas and careers. Rishi digs into his experience at Google, his lessons from spending an intensive summer working with <a href="https://twitter.com/rishi_tripathy_?lang=en">Steve Schlafman</a>, and how he's applying product thinking to the Chief of Staff function at On Deck.</p><p><img class="image_resized" style="width:75%;" src="https://inputwebsite.s3.us-west-2.amazonaws.com/library/rishi_4d40b7751d.png" alt="rishi.png" srcset="https://inputwebsite.s3.us-west-2.amazonaws.com/library/thumbnail_rishi_4d40b7751d.png 234w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/small_rishi_4d40b7751d.png 500w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/medium_rishi_4d40b7751d.png 750w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/large_rishi_4d40b7751d.png 1000w," sizes="100vw"></p><h2>Hey Rishi! Thanks for joining us. So you recently started a new role — congrats. Can you tell us about that?</h2><p>Yeah! So I transitioned away from my product role [Product Manager at On Deck], which was more of a generalist role, into now being the Chief of Staff.</p><p>The way I think of it is, I’m still a PM, but instead of a technology product, my product is the company — the team, the executive team, the board. That’s the framing I’ve given myself.</p><p>So the question is: what should the company be working on? What’s the right thing to build? How do we make sure everybody’s bought in? I'm using a lot of the similar skills that I’ve learned, having done product prior to this, but applied in a different and slightly more abstract context.</p><p>That’s cool. How’d you come to be involved with On Deck? What was your progression like to get to this point?<br>Whenever I talk about this part of my journey, I always start at the beginning of college. I was interested in biotech and basically, I wanted to cure cancer. I very quickly realized that wasn’t gonna happen. I started off doing biomedical engineering, and I did an internship at a medical robotics company. And I realized, healthcare is really slow. I was working on something that wasn’t going to be launched for years and years. I wanted to do something faster, so I transitioned into electrical and computer engineering.</p><p>I did a software engineering internship, which I though was interesting, but at the same time I didn’t feel like I had enough context on why I was building what I was building. That was the piece I was missing. I liked the technology, but I didn’t really know how it was being used, or why I was being paid to build it. So at that point I started to think that, based on my experience, I'm someone who needs to understand the context of what I’m building, and I want to move fast.</p><p>That drove me toward product work. I'd heard about <a href="https://careers.google.com/programs/apm/">Google’s APM program</a> — apparently a lot of people say good things about it. I applied, and there were some folks at Duke who had done it in the past and were generous to enough to help me out with preparing.</p><h2>Nice. What was your time at Google like? And your journey from there?</h2><p>I did the internship in summer 2019. I had an amazing experience. Really, it was great. There was a great community, I was learning a lot, sort of like a structured mentorship. I really got to understand how a big company works.</p><p>Ultimately, there were parts that didn’t 100% jibe with my own work style. Sometimes the company just felt so big, there were so many different groups with their own distinct goals. That creates almost a sense of competition, and I wondered, why do I feel like I’m working head on with people I should be collaborating with?</p><p>So I thought, if I were to come back, I’d like to be part of a smaller team that’s not working too broadly across all of Google. Working broadly like that is a skillset, of course. But I really wanted to learn how to build cool stuff. So I accepted a return offer to Google, and they had me fill out a form to express my preferences for where I wanted to work. I told them that I really wanted to be part of a small team, just a few engineers and a designer, maybe. And I wanted to be working toward solving a very specific problem for a very specific user group. Technology from the ground up. It didn’t need to be glamorous, I just wanted to figure out, “how do you build the right thing?”</p><p>Which, it turns out, is the core of product management.</p><p>I got the perfect team — they assigned me a small education team. And education is an interest of mine, which was great.</p><p>I was ready, I had signed the offer last fall. And then through the summer, I did some work in the startup scene with Steve Schlafman, an angel investor and venture capitalist based out of New York.</p><p>I worked with him doing sort of an apprenticeship. I thought I knew how the startup ecosystem worked beforehand, but I really didn’t understand it until I did that apprenticeship. I got to see how stuff really gets done. It was a really, really formative and incredible experience for me.</p><p>I publicly shared some of the work I was doing to support founders, and I ended up hearing from the On Deck team. They were like, “hey, we’re building something in the startup space, we’re helping founders, furthering education, bringing people together, creating community” — all of that was really interesting to me!</p><p>I was so blown away by the caliber of the team, the mission, the vision, the possibilities for growth — so I ended up signing the offer to join On Deck instead.</p><h2>You mentioned that working with Steve taught you a number of things about the startup ecosystem that really surprised you. What were some of the lessons you learned?</h2><p>I’m so grateful for that experience. He basically had me riding shotgun all summer, sitting in pitch meetings with founders, reviewing deals, doing diligence, learning how the entire capital network and founder ecosystem play together.</p><p>I was learning a lot about how companies start, and grow. And it was so inspiring. I realized that, although I was really excited for my job at Google, I was nowhere near as excited as the founders we met with were about the things they were building.</p><p>I’d say I’m pretty entrepreneurial, and that experience really reinvigorated me. I thought, wow, that seems really cool, to be on a journey where you’re that excited about your work.</p><p>And that’s a big problem I see — so many people are unhappy with their work. Maybe I’m pontificating a little, but if we’re going to spend a third or more of our life on something, we might as well enjoy it.</p><p>At the same time, that summer I also learned that the hardest thing is meeting with founders who are really trying to further a mission, and having to say “sorry, we just don’t see it the same way.”</p><p><i>[You can read more about Rishi’s summer with Schlaf </i><a href="https://ikiguy.substack.com/p/whats-cookin-reflections-on-a-summer"><i>here</i></a><i>, and his last-minute decision to join On Deck instead of Google </i><a href="https://ikiguy.substack.com/p/the-google-apm-dropout-late-registration"><i>here</i></a><i>.]</i></p><h2>You mentioned education — what is it about that space that interests you?</h2><p>I’ve always been a really curious person, and I’m really grateful that I was raised in a family that encouraged that in me. I was never told that I was asking too many questions.</p><p>At the same time, school and college were often frustrating because I felt like I wasn’t learning what I wanted to. Plus, schools have no incentive to help their students succeed, beyond ensuring that they can get alumni donations. I just think education can be a lot better.</p><p>And I think that if we can show people what’s possible in the world, they can make much better informed decisions about how they want to spend their time, and what they want to work on. So education is really important.</p><p>The combination of education and entrepreneurship in particular is really valuable, because they’re positive. It’s not zero sum. If you’re educating people, you’re not creating scarcity and selling that. Instead, you’re almost creating something out of nothing. Best of all, once you receive an education, whether you paid for it or not, nobody can ever it take it away from you.</p><h2>Love that framing! How does the product culture at On Deck differ from what you’ve seen or heard about elsewhere?</h2><p>One thing that stands out is the culture of experimentation. We experiment with everything, from the literal software product that we’re building to support our communities, to the programming, to even the actual fellowships that we launch.</p><p>One of the first initiatives I led when I joined was the launch of On Deck Labs, which is our business unit that essentially tests out new fellowship ideas for communities that we can build around the identities of ambitious people. We’re really encouraged to get feedback from the external world, from our customers and users, and people who want to see us succeed, as well as our detractors and people who are skeptical of what we’re building.</p><p>Everybody is very customer-focused and mission-driven, which really impacts the way we interface with our community. I’ve really grown to believe that every function is a product function — you have a goal, you’re trying to design a process that works. Sure, you can say “well, everything is also engineering and everything is also design.” But I think there’s something to the idea that we want to choose a set of outcomes, and we’re going to do what it takes to get there.</p><h2>So how do you view your new role through that lens? What are things you can do when running a staff function that people normally don’t think of?</h2><p>The Chief of Staff function is kind of unique, because the job is essentially to supercharge the company, the leadership team and the board to make sure we’re working on the right things.</p><p>And what you’re building is a company and a culture, and a leadership team that is empowered to do their best work. I think there are a lot of interesting opportunities in a remote environment in particular, working with a distributed team, where we have access to so many different tools.</p><p>You're also thinking about how to manage constraints. Constraints around a product team might be timeline or engineering resources, for example. Whereas constraints I’m looking at are, “where is people’s attention divided? What do people care about internally? How can I collect qualitative data and look at metrics, and figure out ways for us to work at an extremely high bandwidth, but independently?”</p><p>And just like in a product function, your goal is to align people. In a distributed, remote team, what’s important is making sure that everybody has the shared context, that they’re able to do their best work and make good decisions. We don’t need everything coming top-down from the CEO. So how do we use Slack and Notion and Docs and the Drive to create shared context on goals and priorities? That’s the framework I’m attempting to build out.</p><p>It’s all about sharing context, as opposed to control.</p><p>Long story short, as a PM my job might be to unblock engineers and designers and marketers and big decision-makers, so it’s not that different. I still identify as a PM in this role.</p><h2>On Deck started off in-person, correct, and has now transitioned to remote?</h2><p>Yeah, it was a dinner series for three years, and then an in-person cohort for ODF1 and ODF2, and now we’ve transitioned to completely remote. That has enabled a lot of interesting things for us.</p><p>Number one is the power of technology — we’re now accessible to people around the world. Before, people were coming from SF, New York, etc. But now we have fellows from all over the world. It brings an incredible amount of diversity and perspective to the community, which just makes everything better.</p><p>We’ve also started to build tools to support the community at a global scale. On top of that, the team has essentially tripled in size since I’ve been here, and that’s way harder to achieve in person. In a way, remote has been a sort of forcing function that requires us to get our shit together and make sure we’re all growing in the same direction.</p><h2>Do you have any practices that you think are unique to your team that are really useful when working remotely?</h2><p>Yes. I’d say our internal community Slacks are the best Slack workspaces I’ve ever been in. There are a lot of best practices and tips and tricks we’ve learned over time. I think the average team, from what I’ve observed, uses something like 20-25% of the features of Slack or Zoom on a day-to-day basis. Whereas we’re always pushing the envelope. When we get the release notes from Zoom or Notion, we’re always like “wow, these features now exist! How can we use them?” So our team is always looking for ways to push the envelope.</p><p>Another thing we do is try to prototype everything in no-code first. So some combination of Slack, Airtable, Webflow, whatever — that way we can spin up prototypes really quickly, and see if a concept resonates with our fellows. And once we start to outgrow those tools, we’ll build it into software. That allows us to have a happy product team, and happy engineers, because we’ve already validated everything and we know it has product market fit. We’re clear on what the pain points are, we’ve got feedback — that approach really helps us out.</p><h2>That’s awesome. Have you read anything recently that you’ve found super helpful?</h2><p>I just stress-read <a href="https://www.goodreads.com/book/show/38821039-the-making-of-a-manager">The Making of a Manager</a>, by Julie Zhuo. I have a couple of interns I’m now working with, who are amazing. Basically I graduated from college and now I’m managing people, so I'm on a steep learning curve and that was really helpful for me.</p><h2>Do you have any favorite apps or products right now?</h2><p>I just started using <a href="https://sunsama.com/">Sunsama</a> as a collaborative product, working with our CEO, and I’m finding it really useful. It helps us to understand what’s on our plate, where we should be focusing, how we make the most of our days, etc.</p><h2>Thanks so much, Rishi!</h2><p><i>For more from Rishi, check out </i><a href="https://rishitripathy.me/473be1006a35497e825c57205fbbcd21"><i>his website</i></a><i> or </i><a href="https://ikiguy.substack.com/"><i>sign up for his newsletter</i></a><i>. And if you wanna get our Product Thinking interviews in your inbox, sign up for our monthly newsletter below.</i></p>

Output_Cover_Rishi.jpg

Output_Header_Rishi.jpg

An interview with Rishi Tripathy

<p>Today we're speaking with Paul Ortchanian, who runs <a href="https://www.bainpublic.com/">Bain Public</a>, a Montreal-based product consultancy that helps businesses of all sizes develop and implement strong product management practices.</p><p><img class="image_resized" style="width:75%;" src="https://inputwebsite.s3.us-west-2.amazonaws.com/library/paulortchanian_jpg_2e4953b1ff.jpg" alt="paulortchanian.jpg.jpg" srcset="https://inputwebsite.s3.us-west-2.amazonaws.com/library/thumbnail_paulortchanian_jpg_2e4953b1ff.jpg 156w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/small_paulortchanian_jpg_2e4953b1ff.jpg 500w," sizes="100vw"></p><h2>Thanks for joining us, Paul! First, can you tell us a little bit about your journey? How’d you get started, and how’d you end up where you are today running Bain Public?</h2><p>Sure! I started off as an engineer. I did about 10 years of engineering, mainly on the front-end side of things. I was very close to UX, too, and eventually ended up managing scope on bigger projects. And when you’re working on big products, you really start to realize how important the management of scope and expectation are to creating clarity.</p><p>Because I loved UX as well as working on the business side of things, I made a leap of faith and became a Product Manager in San Francisco. I joined a startup and learned things the way many product managers do — the hard way.</p><p>Eventually I came to Montreal and realized we had a nice little startup ecosystem, but most of the companies here didn’t have a culture that was product-led. It was the same old story of, “do what the boss says.” These business weren’t really solving customer problems, but instead trying to build as many features as they could without really asking themselves the question: is this adding value?</p><p>So I decided to start a company that focuses mainly on evangelizing product management to the Montreal community. I try to bring some of my key learnings from San Francisco to Montreal, and implement product-led thinking.</p><p>We have a mix of companies here, both early startups and later-stage ones. Regardless of stage, many are in denial for awhile, and eventually realize that product is important. But they’re not sure how to go about improving things. And that’s become our niche.</p><h2>That’s great. Thinking about organizational transformation, let’s say you have a bigger company that doesn’t have a very effective product culture. What are some things you’ve seen that are signs a company needs help, or needs to be thinking about product in a different way?</h2><p>First up, defining what a product manager does is quite important. So if I were to ask the company’s product managers, what do you do every day? How do you define your role in your company? Ideally, the answer is “we’re taking ownership of a portion of the company’s growth, through the features that we’re launching, and we’re able to help the business achieve its next financial milestone.”</p><p>There needs to be some acknowledgement that sales or marketing are not the primary drivers of business growth. And that the product itself is going to contribute positively, by increasing revenue through upselling, preventing customers from leaving, finding ways to charge more for certain things, adding ways to acquire new customers, and so on.</p><p>We’ll ask the product team, “what’s the strategy? Are you making large bets on unproven markets? Are you competitively launching new features? Are you extending a product functionality to an established market? Or are you simply shipping with little discussion about impact?” If it’s the latter — simply shipping, with little discussion about impact — that’s a project manager, not a product manager. Because they’re being told what to do.</p><p>So then I go to the product leadership team, usually the C-suite, and take a reverse lens. I’ll ask them, “what do you expect out of a product manager?”</p><p>And you can tell based on their answers if it’s an organization that celebrates shipping features more than it celebrates solving customer problems, or business problems. That’s the starting point.</p><h2>I like that framing. So let’s say someone is in a culture like that, and they want to implement better product-led thinking. But they’re not in the C-suite. What are some things they can do?</h2><p>Usually I try to define the strategy with the product leadership team before defining product management. It’s a question for the founders, the top-level decision makers. Usually that includes sales and marketing, operations, the CTO, and so on. And the question really is, “is this plane being built as it’s flying off the cliff, or is there a plan? How do you empower your product management team through processes and tools?”</p><p>It just comes down to asking some pretty tough questions. The best question I’ve been able to ask is, “do you know which features in your product are contributing toward revenue? And directly or indirectly, which are the largest customers that are using those features?” Take a very metrics-driven approach.</p><p>And if they’re unable to answer that, and they say “well, the product sells itself,” or, “we have no clue, because we have an amazing sales team and they’re able to sell anything,” or “our marketing team works really hard to bring in new customers,” — then, they really don’t know.</p><p>I recently had a startup founder email me his monthly report, outlining an increase in the number of commits to his main code repository. He was celebrating that as a win. And he was really happy about a questionnaire they sent out that had a lot of responses. I wrote him back and said, “you know, those are very shallow KPIs.”</p><p>You can’t run a business focused on shallow KPIs. You need to know how much growth each feature is generating, and how each feature is contributing to achieving your next financial milestone. If you can’t answer that question, then you don’t have a product-led culture.</p><p>But once people see how that type of thinking can contribute to the business, it can start to infiltrate the company. On our end, we come in to help define that step-by-step process, as long as the leadership team is willing to make the change.</p><h2>What are some challenges you’re facing right now in your role, running Bain Public?</h2><p>First of all, doing what we do, coming in and saying to a company, “you’re gonna have to make all this change,” — that’s a pretty tough sell. You need a lot of credibility. People want to know your background, and they want to know you know about their industry. Oftentimes I hear, “what do you know about the [healthcare / fintech / etc.] space?” But it’s not about that. The reality is, our job is to come in, interview the team, get to know their product culture, and help them put in place a process to empower product managers and inject this type of thinking in their company. They’ll always be the experts at what they do. We’re just there to organize priorities, help work through the roadmap to make sure it’s contributing to the growth of the organization. So this is an ongoing challenge, creating the organic word of mouth and the pedigree to allow us to be credible.</p><p>The second challenge we face is the product management culture within organizations. Oftentimes you’ll get someone who wasn’t hired as a product manager — maybe they came in as a business analyst, a UX designer, a marketer, or something like that — and they’ve been effectively given the role of product manager.</p><p>In many cases, they’re extremely busy, they’re running the show without any work-life balance, and they’re just unwilling to stop and make changes.</p><p>I read a Reddit thread recently that talked about how the role of a PM is a lot less glorious than what you see portrayed. And that’s true. A lot of it is a grind. You’ve got to drop something to jump into a customer support call, and then you run to a sales meeting to make sure the sales team doesn’t sell stuff that doesn’t exist, and then you head over to marketing to explain the features you’re actually shipping, and help them with website copy to make sure it’s accurate. It’s a grind.</p><p>People get caught up in it and think, there’s no way to progress here. External people can’t come in and coach me. It’s denial, really. Because there’s so much growing and learning that needs to be done in this space.</p><p>They might be busy debating whether to use Kanban or Agile, but ignoring the fact that every day their boss, who suffers from Shiny Object Syndrome, comes in and whiplashes the team with a new feature. So which problem do they really want to solve: Kanban vs. Agile, or the fact that their boss doesn’t let them have a roadmap?</p><p>Willingness to be challenged needs to come from the leadership team and PMs alike.</p><h2>By definition, you must be dealing almost exclusively with clients that are suffering from these challenges but at least looking to resolve them.</h2><p>Yes, though I’d say there’s a large percentage of clients we work with that don’t even know what product management is.</p><p>That’s another problem. Maybe they’re brand new companies, they might even be pre-seed or at the ideation stage. Ideally, they’re looking to implement a product-led culture from the get-go, because the longer they delay, the more problems they’re going to have in terms of communication and culture down the road.</p><h2>You just mentioned Shiny Object Syndrome. I think sometimes people are resistant to having a data-led approach to product decisions, because they think they know best, or their solution is new and they think the customer doesn’t know what they want. So they’re just going to be the visionary that drives this product.</h2><h2>How can a PM help facilitate a more rigorous approach to decision making?</h2><p>We do <a href="https://blog.bainpublic.com/post/bain-public-soap">SOAP</a>, which is our framework. We bring in the entire product leadership team plus the PM. So that’s usually 4-5 people — CEO, CFO, CMO, etc., plus the PM. And we basically conduct interviews. We allow them to express what they think the priorities are from every angle.</p><p>Sometimes it’s not about making the right decision, it’s about making sure you have the right process, which is this collaborative discussion. This quest for learning together. So if you’re a PM, you’re in a position where you can get everyone together and help them learn. What are the constraints the sales team is facing? What about the marketing team? What’s customer support hearing?</p><p>And then the goal is to come face-to-face with the really hard problems, together. That way, there’s no one-sided bias from the sales team, or the marketing team, or the engineering team.</p><p>It’s all about asking the right questions, too. When they say they need something, follow up with a question: “how is this going to help the business? How is this going to allow us to achieve our financial targets? If this is a great idea, who’s the user that’s going to use it?”</p><p>This process of collective learning helps create trust in the PM, because people can see that the PM isn’t just dictating things. There are no egos in the room.</p><p>You might not bat for a thousand, but at least you’ll be able to hit, say, a 60% average in shipping the right features. And over the long run, that’s probably good enough.</p><h2>Great advice. So how can you balance short, medium and long term goals when setting a roadmap?</h2><p>It’s like wearing glasses — the closer things are, the sharper they get. The further out you look, the more blurry it gets. The crucial thing is always getting the next three months right, facing your immediate decisions.</p><p>Beyond that, your customers might change. Your competitors might change. Your market might change. You’ve got to be able to reevaluate every three months or so. That’s why we called our company Bain Public, because in French, bain public is a public bath. It’s a place where you go to clean up on a regular basis.</p><p>So the idea is, every three months a company cleans up their roadmap. Reevaluates what’s happening. It’s not about having full clarity on a 6 to 12 month roadmap. It’s mainly about having a high level mission.</p><p>You can have long term goals, but know that they’re blurry.</p><p>And in terms of setting top priorities, it’s best to come face to face with the worst problems. Often the company’s worst problems are the customer’s worst problems. Maybe something is broken and it’s creating a ton of support tickets. And you’re stuck with one resource who’s managing 600 tickets a day, which is humiliating. When you think about it that way — what’s humiliating? That gives you a good idea where to start.</p><h2>What about a new startup that’s just launching for the first time? How can they think about prioritization?</h2><p>Well I guess that’s your biggest problem, no one is using the product yet. First up you want to create your whole ecosystem. How does somebody buy your product? What happens post-purchase? Map out every step you want a customer to take from sale, to regular usage, and the output the product provides.</p><p>Then you ask yourself, “where are we faking it till we make it?”</p><p>When you look at your process, what you’ve built and what you’re faking, where are there gaps that could create problems for the customer? If something important isn’t yet automated, or data is being stored somewhere it could easily be lost, you probably want to start there.</p><h2>What about PMs early in their career? What’s something you wish you’d known earlier?</h2><p>I would’ve loved to be coached from the get-go. I used to be the guy who came into the room with the data, the numbers. Everything you read about product management, people are telling you to be an expert in the data, the market, your competitors, your industry. So you’ve spent time with the CTO and the engineering team. You’re an expert in the product and the database structure. You’re in sales and marketing meetings. And you think, “okay, I guess I’m an expert on everything and I’m here to tell everyone what the facts are.”</p><p>The thing is, product managers also need to be able to influence people. You need to be able to hear them out, hear their concerns, and frame the features you’re proposing within the context of their problems. And if you’re not listening, and you’re just the guy who’s coming in with the facts, you’re going to get challenged or pushed aside. And that was my biggest issue, originally. In my first PM role, I was fired. Not because I was a bad PM, but because I had a big mouth.</p><p>Once you lose credibility, you lose the room. It’s like being a hockey coach. It’s not because you’re bad, it’s because the players don’t want to play for you anymore.</p><p>The average lifespan of a PM within a company is often a year. It’s ridiculously short. I think a lot of it has to do with the fact that PMs have so much to assimilate in a short amount of time.</p><p>I talk a lot, and I had to learn the hard way to be a good listener. Maybe it’s not a good idea to go out there presenting a list of 10 Reasons Why We Shouldn’t Build This Feature, because the sales team is going to just go around you to the CEO and get their feature built.</p><h2>That’s good advice, and very true. Last couple questions! What’s a product that you’re obsessed with right now?</h2><p>One that I’ve always liked — I’ve been using it for about 10 years now, I think — is <a href="https://culturedcode.com/things/">Things</a>. It’s basically just a big to-do list. But the way the user experience has been thought out is great. Every feature adds value. I can’t get out of it, it’s just so much part of my day-to-day.</p><h2>Any recent podcasts or books you’ve discovered that you’d recommend?</h2><p>I love Todd Olson’s book, <a href="https://www.pendo.io/the-product-led-organization/">The Product Led Organization</a>. It’s basically Product Management 101. I find the industry is becoming more mature, and I’m really happy that there are books like this that are the real deal.</p><p><i>For more from Paul on product management, dive into </i><a href="https://blog.bainpublic.com/"><i>the Bain Public blog</i></a><i>. And make sure you never miss a Product Thinking interview — sign up for our newsletter below.</i></p>

Output_Cover_BainPublic.jpg

Output_Header_BainPublic.jpg

An interview with Paul Ortchanian

<p>Welcome back to our Product Thinking series, where we interview product leaders from a range of roles and organizations to learn about the challenges they're facing, lessons they've learned and advice they have to share for others in the field. Today we're thrilled to be chatting with Emma Townley-Smith, Group Product Manager at <a href="https://www.livongo.com/">Livongo Health</a>.</p><p><img class="image_resized" style="width:75%;" src="https://inputwebsite.s3.us-west-2.amazonaws.com/library/headshot_ETS_jpg_b3623c725a.jpg" alt="headshot_ETS.jpg.jpg" srcset="https://inputwebsite.s3.us-west-2.amazonaws.com/library/thumbnail_headshot_ETS_jpg_b3623c725a.jpg 186w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/small_headshot_ETS_jpg_b3623c725a.jpg 500w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/medium_headshot_ETS_jpg_b3623c725a.jpg 750w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/large_headshot_ETS_jpg_b3623c725a.jpg 1000w," sizes="100vw"></p><h2>Hey Emma! First up, we'd love to know more about your background. What have you worked on in the past, and how'd you end up in your current role? What drew you to product work?</h2><p>I was drawn to product work in college because I really wanted to understand why certain products were more successful than others. When I looked at a blowout success like Facebook, it wasn’t obvious to me why it succeeded instead of MySpace. Or why (at the time) Snapchat was growing so quickly in popularity. I was deeply curious about what made people want to try something new, or switch their solution, or pay.</p><p>I studied Product Design, which helped me build a skillset in user research and problem-first (rather than solution-first) thinking. I started to get a qualitative appreciation for how you assess whether your product is working, and how you build momentum and a story around your early interactions with users.</p><p>All throughout school, I worked part time -- by the time I graduated I had worked at four different companies that ranged from seed stage to Fortune 500. I knew that I wanted to build foundational PM skills on a larger team before returning to an early-stage company, because they needed more leadership from their few product managers than I could offer as a new grad. I built strong consumer foundations in the Capital One Innovation Lab before joining Livongo as an early PM. Over three years, I’ve had the opportunity to grow from an IC working on a collection of features to a manager in more of a GM role, managing a team of PMs and owning multiple product lines.</p><h2>What are the unique challenges you're facing in your role right now?</h2><p>For me personally, I’m in a demanding IC role and managing a team for the first time. I was nervous that the two sets of responsibilities might compete with each other, but they’ve been symbiotic. In order to be effective myself and to maximize the whole team’s impact, there’s no time to dwell on the easily reversible decisions, or to micromanage. The total pressure on my time helps me prioritize my own work clearly and empower my team to move forward.</p><h2>Awesome. And when it comes to product roles, what would you say is your unique ability that has allowed you to succeed?</h2><p>Curiosity has been critically important. There’s no formal training that tells you how to manage hardware and software together, how to persuade executive stakeholders, or how B2B2C is different from your previous B2C role. At this point I have approached a lot of complex product situations without prior experience, and I’ve figured out how to do my homework. Research what other companies have done. Look for a common framework that people use to solve this kind of problem successfully. Interview other PMs. Ask the “obvious” questions and make sure you have the right context.</p><h2>What's one thing you've worked on that you're really proud of?</h2><p>I’m proud of the foundational <a href="https://medium.com/pathtoproduct/machine-learning-is-a-hammer-3015b9e4d72">machine learning</a> and behavior change work that we did at Livongo over the last few years. It’s common both for machine learning and behavior change to be buzzwords without an implementation that’s meaningful to the business’s goals. We’ve worked really hard to bring together technology and strategy to create experiences that actually help people introduce new healthy behaviors, like <a href="https://www.cnbc.com/2019/06/25/livongo-health-nudges-coming-to-apple-watch-fitbit-samsung-watches.html">personalized Health Nudges</a>.</p><h2>When it comes to product, how do you know when to trust data, and when to trust your intuition? Have you ever taken a risk based on your intuition that paid off?</h2><p>It’s a funny question, because my intuition is based on data -- data from past analyses, experiences, or conversations. Most of the product intuition “misses” I’ve seen come from a context mismatch -- trying to apply past experience that aren’t relevant to the current problem. When making assumptions, I’m careful to think about whether the “data” behind my intuition matches the current situation. Is it a similar type of product, objective, customer, team, company stage, etc? Am I sure my past experiences apply here?</p><p>When I’m approaching a decision, I generally think -- have we put the right time and effort constraints on data-gathering relative to the importance of the decision? (To make <a href="https://www.inc.com/jeff-haden/amazon-founder-jeff-bezos-this-is-how-successful-people-make-such-smart-decisions.html">a quick Bezos allusion</a>, is this a reversible decision that may be appropriate to make based on intuition, or do the consequences merit more information?) Given those constraints, do we have all the important inputs we can reasonably gather before we pull the trigger?</p><p>I’ve found that a lot of content work can be successfully driven by strong intuition about what users want. I didn’t do research or analysis before starting <a href="https://medium.com/pathtoproduct">Path to Product</a> (a leading Medium publication on product management), but I knew from my experiences in the early career PM community that there was an appetite for real, on-the-job anecdotes instead of high-level frameworks. I spent about a year writing before things really started to take off, but we’ve grown organically now to over 35,000 followers.</p><h2>Congrats, that's a big achievement! Let's talk about other products — what's your favorite app right now? Why?</h2><p>Not sure I have a favorite app that will wow anyone, but I can think of a recent moment where an app impressed me. I recently became a homeowner, and went through the process of hiring contractors to help with repairs. I was really impressed with the templates that Yelp offered to make sure that you requested quotes with the right contextual information, and the way that they seamlessly delivered your quote request to more vendors to help you get a rapid response. I was expecting to do research about what kind of quote request to send, and to call multiple people myself, but Yelp effortlessly expanded from its core “search” job to meet these other needs. And there was no advertising or feature education involved -- it was a seamless experience within my existing pattern of use.</p><h2>Great example. Last question! Has there been a recent podcast interview that's really wowed you?</h2><p>I enjoyed <a href="https://fs.blog/knowledge-project/jeff-hunter/">Jeff Hunter: Embracing Confusion</a> from The Knowledge Project. His message really resonated with me -- it’s easy to go into work every day on autopilot. You have to approach each day with the intentional goal to get better. You should be watching for emotional reactions or confusion, and in those situations ask not what went wrong, but how you should update your mental model for a better understanding of how to be effective.</p><p><i>For more from Emma, read her work in </i><a href="http://localhost:8080/blog/product-thinking-an-interview-with-emma-townley-smith#:~:text=her%20work%20in-,Path%20to%20Product,-.%20And%20be%20sure"><i>Path to Product</i></a><i>. And be sure to subscribe to our newsletter below to get more Product Thinking interviews from our team at Input Logic!</i></p>

Output_Cover_LivongoHealth.jpg

Output_Header_LivongoHealth.jpg

An interview with Emma Townley-Smith

<p>This is part two of our new series, Product Thinking. We're featuring regular interviews with super-sharp product managers, leaders and thinkers from a huge range of companies. Our last post was <a href="https://www.inputlogic.ca/blog/product-thinking-an-interview-with-den-delimarsky">an interview with Den Delimarsky from Microsoft</a>.</p><p>Today, we're thrilled to be chatting with Andrew Yu, Product Lead on the Biden campaign and a former PM at LinkedIn.</p><p><img class="image_resized" style="width:75%;" src="https://inputwebsite.s3.us-west-2.amazonaws.com/library/andrew_profile_roof_resize_jpg_ff91906ed3.jpg" alt="andrew-profile-roof-resize.jpg.jpg" srcset="https://inputwebsite.s3.us-west-2.amazonaws.com/library/thumbnail_andrew_profile_roof_resize_jpg_ff91906ed3.jpg 155w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/small_andrew_profile_roof_resize_jpg_ff91906ed3.jpg 498w," sizes="100vw"></p><h2>Hi Andrew! Thanks for joining us. First, can you tell us more about your background, how you got into product work, and how you came to be where you are today?</h2><p>So, like many product folks, if not all, there’s no traditional background. I didn’t study anything product related in college. But once I graduated, about 10 years ago, I read some of Paul Graham’s essays and there was a lot about product management. At the time, I had studied politics and wanted to go into politics because I wanted to create impact. But then I realized, that’s such a long-term way to try to create impact, through politics. And when I heard about product management, I thought, not only does this sound really interesting from an intellectual point of view, but also you get to have direct, immediate impact. You work at the intersection of all these teams. So for me, having impact was the theme that tied everything together. And I thought, I’ve gotta get from DC out to San Francisco and become a product manager.</p><h2>How did you get started?</h2><p>Back then, the only way you could really do it was to first become an engineer. So I tried my hardest to learn how to code. And then I got a job as a software engineer. And mind you, I say that super casually, but at the time it was one of the most difficult things I’d ever done. But I made it through and then transitioned from engineering to product. For me, that was always the goal.</p><h2>Cool. How’d you learn to code, and what was your journey into product?</h2><p>Yeah, let’s dig into that! It was a combination of three things. First was just teaching myself to code. The second was talking about it to almost everyone I could. That was key. I went to meetups, I was a complete n00b. I literally remember asking someone, “what is an API?” That’s how fresh I was. And then third, I got hired to code and was able to learn on the job. That was one of the luckiest parts of the whole journey. In your career your get maybe two or three things that are just complete luck. And for me, that was definitely one of them. But part of the reason it happened was because I had been talking about it so much. I was networking a lot. I was just obsessed with it at the the time. And this startup team said, “you know what? We know you want to code, we know you’re this young kid who’s energetic and wants to make it happen. So we’ll actually teach you on the job, if you’ll join and be a ‘do everything’ kind of person.” It was really great.</p><p>From there, I got my first product gig, and then I asked myself, ‘what other problem spaces do I wanna work in?’ I moved to an education technology company where I really learned the ins and outs of product management. And then I went to LinkedIn. That’s where I really learned some of the best practices. Their processes and operations are so well established.</p><p>And recently I left LinkedIn, and worked on the Biden campaign. It’s been one of the most unique and interesting product experiences I’ve had.</p><h2>Do you still code? Is it useful as a PM?</h2><p>That’s a timely question! I hadn’t really been coding since I went into product. It was a means to an end. But I recently started coding again, just for fun. The reality is, you really don’t need to code to be a product manager. It’s not like it used to be. Now you’ve got people coming in from MBA programs, management consulting, all over the place. But there are definitely a big group of PMs who are former engineers.</p><p>I would code here and there. I also took a data science class because I knew it was important, especially if I wanted to work in a machine learning space. You need to understand how to implement models.</p><h2>Can you tell us more about what you’ve been working on with the Biden campaign?</h2><p>I can tell you as much as I’m allowed to! The short answer is, it’s still going on, although it’s a little less involved now. I’m on the post-election team, addressing the question, ‘what happens after election day?’ That required a lot of setup. There’s a lot of work to be done leading up to it. The team is essentially focused on election protection.</p><h2>So you’re really in the thick of it!</h2><p>Yeah. I mean, it was all hands on deck for seven days a week for a couple of weeks.</p><h2>Really interesting. How was that to work on, given that you’d studied politics, then went into tech, and now you’ve been working kind of at the intersection of those two things?</h2><p>That’s a great question. In a lot of ways, you caught me at a very specific time in my career. This is not at all what I thought I would be doing. I left LinkedIn in August, and it was one of those things where you make a move and opportunities appear. I left on good terms and I was just looking for my next step. And if I were still working at LinkedIn, or anywhere full-time, I would not have even been open to doing something like this. That was part of why I left — I knew that I was trying to go into the next phase of my career.</p><p>I’m a very firm believer that are phases to your career. You have to instigate change, because it won’t happen on its own.</p><p>That’s what’s happened my entire career. Questions like, am I going to learn to code, or not? Am I going to move to SF, or not? Am I going to leave this role, or not? And it was just one of those times. Of course it takes a lot of thought and planning ahead of time.</p><h2>How did you end up joining the Biden campaign?</h2><p>Because of Twitter. Twitter is the reason we’re even talking, right?! I always knew it was powerful, but when you actually start taking action on Twitter, and you get real outcomes from it, you think, ‘oh okay, there’s so much here that’s untapped!’</p><p>This wasn’t even my plan. I was planning to just be in a creative mode, take a break, work on stuff I want to work on. But someone who was involved in the Biden campaign posted a role, I connected with them, and I didn’t end up getting that role but they reached out to me with this one.</p><h2>Awesome! Do you have advice for people who want to engage more on Twitter? How do they start taking advantage of it?</h2><p>Yeah! There are two main things that, if you do them, are pretty much bulletproof. You’ll get something out of it. First, focus on giving and contributing above everything else. And what I love about that is, it’s not only altruistic. Not only are you contributing to others, but you’re also helping yourself, building up your brand.<a href="https://andrewyu.substack.com/p/servant-networking-serve-dont-network"> I wrote an article about what I call ‘servant networking</a>. You’ve heard of servant leadership, which is about serving not leading. And it’s the same with networking. If you keep giving people stuff, the key is not to expect anything in return. Guaranteed, good things will come back to you. But then again, the whole is to do this mind trick where you truly do not expect anything in return.</p><p>One useful way to contribute, though, is to share summaries. I recently saw someone say, “hey, there’s a book that’s really popular right now, I know you don’t have time to read it so here’s a summary.” That’s contributing! That’s serving.</p><p>I took the <a href="https://writeofpassage.school/">Write of Passage</a> course with David Perell, and it really made me see the internet differently. It was dope. One of the main things he emphasizes is to write so that people can discover you. It helps you connect to people around the world.</p><p>The second thing when it comes to Twitter, is this: DM everyone. Everyone is reachable! Maybe people don’t realize that yet. I’ve straight up just started treating Twitter like Slack. It’s a Slack where everyone in the world is on it. So I just DM people, and I’ve managed to get on Zoom calls with people who are way more senior, people that I normally wouldn’t be able to talk to.&nbsp;</p><h2>That’s great advice! So let’s chat about product management. What do you think is your unique ability that has allowed you to succeed in product roles? How did you develop it?</h2><p>Good question. I’ve heard a variant of that question recently, which a lot of senior people ask. It’s “what’s your superpower?” And I think what that question is getting at is, how does your judgment work? Why is something your superpower? It’s really interesting to think about.</p><p>For me, I think it’s identifying skills gaps and talent gaps, and filling them. Realizing, “oh okay, I’m not great at this thing. Experimentation, for example. So I want to fill that role as well as I possibly can.” Maybe if I can’t fill the role, I can read all about it and learn more. But my unique ability is identifying those gaps, and filling them ASAP.</p><p>You can go pretty far being highly personable, a people person. But nothing beats having the skills. So developing the skills, identifying when there are gaps, and filling those gaps ASAP.</p><h2>When you’re hiring and trying to fill a skill gap of your own, how do you choose the right person?</h2><p>Yeah, that’s really key. It’s all about having the right team to help you evaluate. Of course, if you’re at a giant company they have processes around this. But if you’re at a startup, maybe you provide your opinion, but someone with different expertise on your team may provide a completely different point of view. So it’s huge to be able to know when you can’t identify something, and know who to ask for an opinion.</p><h2>Definitely! So, circling back to LinkedIn, what’s something you worked on that you’re really proud of?</h2><p>I’d say it was the My Network tab. When you open LinkedIn right now, it’s the tab next to the homepage. Basically, our team’s mission was to help people connect to the right people and build their networks. When I joined, that page was just about connecting to other people. By the time I left, we had created an ecosystem where you could discover all the different things on LinkedIn – groups, events, pages, interests, etc. We call them ‘edges,’ — if you follow something, that’s an edge. If you join a group, that’s an edge. If you attend an event, that’s an edge in the LinkedIn graph. So we built that page to connect people to edges. What I’m most proud of is helping to create this entire discovery ecosystem.</p><h2>What was the biggest challenge you faced in doing that?</h2><p>We worked with so many teams to make this project happen. The follows team, which is completely separate from the growth team that I was on. We worked with the groups team, the machine learning recommendations team, the team that builds pages. There were so many teams involved, and from the outside it may not look like that. And that’s the goal, for the product not to reflect that. But internally, it involved a lot of collaboration. Every team has their own goals and metrics. So you need a lot of meetings, a lot of alignment, which is really challenging, but really rewarding. You get to see that to build something like this, it takes a lot of human beings.</p><h2>Definitely. When it comes to making product decisions, how do you know when to trust data and when to trust your intuition?</h2><p>Well, I’ve heard intuition defined as something that results from having accrued a ton of experience and data. Personally, in terms of Myers-Briggs types I’m an ENFJ, a feeler. I love doing things based on feel. So I had to really train on using data early in my career. In general, the first thing I do is trust the data. In general, over-relying on intuition can go wrong. Usually people rely on what I would call ‘perceived intuition,’ when they don’t actually have it. Intuition is almost a privilege, you build it up after years of experience. I’ve seen certain director-level people at LinkedIn who can make a call because it’s clear to them. They’ve seen so much data already over the years that they know the answer. But you should always trust the data, assuming it’s good data.</p><h2>What’s your favorite app right now, and why?</h2><p>Roam Research. It’s hard to explain, it’s not a note-taking app per se. But I live in it now. Here’s what’s interesting about it: products are meant to solve a problem based on a user need. Why I like Roam so much is that it does what some of the best products do, which is show you a need that you didn’t even really know you had. Networked thought, connecting thoughts. I didn’t even realize that was something I would benefit from. I used Evernote for 10 years. I always wanted the ability to pull in blocks of text from other notes. I had this desire, but there was a next step above it that I personally hadn’t seen, which they did, where you can connect different notes to each other — not just reference them, but actually connect them to each other. So I’m obsessed with it. It’s a great tool.</p><h2>If someone wanted to get started in product and they were just beginning their career, what would you suggest they do next?</h2><p>I’d say, start by watching as many <a href="https://www.youtube.com/channel/UC6hlQ0x6kPbAGjYkoz53cvA">Product School talks on YouTube</a> as you can. Personally, I’ve given a couple talks there. They have people who are actual product managers, who are talking about the topics they want to talk about. And Product School provides them a platform and exposure. It’s win-win, and as a result they have so much great content. I’ve been watching their product talks for years. And I’ve learned things from specific talks that have been some of the more valuable lessons in my entire product career. I’ve also watched talks, and then ended up working with the people who gave the talk down the road, which is really reinforcing. Also, you can just reach out to these people! After you’ve watched a talk, send someone a DM. Never say, “hey, great talk. I’d love to pick your brain.” But ask specific questions. Like, “hey, regarding experimentation, you said we should do X, Y and Z. I want to clarify something about that.” Be really precise. And people will often respond. That’s my advice!</p><p><i>To hear more from Andrew, check out his </i><a href="https://andrewyu.substack.com/)"><i>Substack</i></a><i>. And if you’re enjoying our Product Thinking interviews, make sure you sign up to receive our newsletter below! We have lots more coming up.</i></p><p>&nbsp;</p>

Output_Cover_ProductLeadAndrew.jpg

Output_Header_ProductLeadAndrew.jpg

An interview with Andrew Yu

<p>Welcome to our new series, Product Thinking! We'll be featuring regular interviews with super-sharp product managers, leaders and thinkers from a huge range of companies. Know someone who you think we should interview? Drop us a line!</p><p>We're stoked to be kicking the series off with an interview with Den Delimarsky, Principle Cloud Advocate at Microsoft.</p><p><img class="image_resized" style="width:75%;" src="https://inputwebsite.s3.us-west-2.amazonaws.com/library/12039596_10205221788726492_6369753080506531492_n_2_jpg_877a5fc941.jpg" alt="12039596_10205221788726492_6369753080506531492_n_(2).jpg.jpg" srcset="https://inputwebsite.s3.us-west-2.amazonaws.com/library/thumbnail_12039596_10205221788726492_6369753080506531492_n_2_jpg_877a5fc941.jpg 188w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/small_12039596_10205221788726492_6369753080506531492_n_2_jpg_877a5fc941.jpg 500w," sizes="100vw"></p><h2>Hey Den! Tell us more about your background. What have you worked on in the past, and how'd you end up in your current role? What drew you to product work?</h2><p>I grew up always wanting to work in the IT industry in some shape or form, but when I thought about it, it was largely around the software engineering discipline. That is — I had no idea in my high school days that a product management track was even an option. Once I got into the computer science program during my college days, I discovered that there was such a thing as PM. I wrote about it in my blog — it was entirely an accident. However, once I discovered that product management is a thing, it was easily the best decision in my life to pursue this career path. The first steps of me being a product manager happened in early 2013, when I was part of a team at Microsoft that was called Home Activities &amp; Experiences (HAX). As a PM intern, I was responsible for helping bring to market an innovative calendar planning solution. I loved the kind of work I could put into the discovery phases, customer interviews, and then be able to see the ideas take shape in close collaboration with my engineering peers. In broad terms, product management combined two of my favorite things — talking to people and the magic of software. Since then, I've worked on the team that shipped Outlook Desktop and Office 365 Groups, after which I jumped on the opportunity to build <a href="http://localhost:8080/blog/docs.microsoft.com">docs.microsoft.com</a> from scratch, being one of the first PMs on the project. My latest gig was with Amazon, where I helped build parts of the EventBridge service. What I love about being a product manager, and what reaffirms that I made the decision on a daily basis is the sheer scope of work that I get to do — it's practically unlimited. I get to do everything, from talking to people who use the product I am building, to crunching numbers, and mocking up new experience designs.</p><h2>What are the unique challenges you're facing in your role right now?</h2><p>The challenges are not typical to my role, but likely are typical to the times we're in right now. COVID-19 has shown us that we'll need to adapt to a world with stressors that many of us have not seen before. Folks with kids, homeschooling, travel restrictions — these significantly impact our ability to focus and concentrate on building. The situation that we are in right now requires a degree of empathy from our leaders and peers — not everything will get done the way we planned early in the year. Availability of individuals may shift. Attitudes may shift. We all need to be cognizant of these factors. As one of my mentors says, <i>"we're not working remotely. We are working remotely during a global pandemic."</i> This is not your typical 'work from home' environment.</p><h2>What is your unique ability that has allowed you to succeed in product roles?</h2><p>kill stacking. Something that I've learned from my good friend and mentor <a href="https://twitter.com/danielfe">Dan Fernandez</a>. The idea behind this is fairly simple — generalization instead of super-specialization. I tend to combine a set of skills to get the job done. For example, I love writing code and working with data. This enabled me to leverage those skills in my career and help me be more efficient with my and my team's time. With code, I am able to quickly put together product prototypes or help unblock the engineering team when they have too much on their plate. I recall in 2017, when my team was tasked with building some documentation infrastructure, one of the tools that needed to be built was temporarily de-prioritized. I knew we had a tight deadline ahead, so I rolled my sleeves and wrote the tool myself. As far as I am aware, it's still in production today. Being able to wrangle data and discern meaningful insights from those that are irrelevant helped me quickly make decisions and settle arguments without having to be bottlenecked by the data science team, since their resources are scarce and likely already spread fairly thin. Notice how I don't say that I will do the work of the data science or engineering teams — they do extensive work, and are vastly more experienced in their domains than I am. I am pretty sure if they looked at some of my original code, they'd be horrified. However, it enables me to move fast and help my team deliver value to customers regularly. To all the folks that I mentor, I always recommend exploring some adjacent fields. Do you like user experience design? Are you a great orator? Do you have a knack for putting together great video reels? Put those skills to use. A product manager who only knows how to talk to customers and write a spec is silo-ed. A product manager who knows how to talk to customers, write a spec, put that into a Figma prototype, and pull the quantitative data to prove or disprove their product hypotheses is a force of nature.</p><h2>What's one thing you've worked on that you're really proud of?</h2><p>Hard to pinpoint just one thing, to be honest. I've been fortunate to work with really talented individuals in every team that I've been a part of, and we delivered great products. I'd say the most impactful product that I've been a part of was <a href="https://docs.microsoft.com/en-us/">docs.microsoft.com</a> — the technical documentation site for Microsoft. It's an absolutely massive project, with hundreds of stakeholders within the company, and millions of stakeholders outside it. I joined the team in 2015, in the very early planning stages of the site. It was exciting to build something modern, scalable, and with global reach, while considering the legacy of resources such as the Microsoft Developer Network (MSDN) and TechNet. We completely upended the traditional technical documentation model. No more proprietary systems — it's all on GitHub and written in Markdown. There are multiple modalities that allow you to discover every single API that Microsoft ships for a language, such as the <a href="https://docs.microsoft.com/en-us/python/api/">Python API Browser</a> or the <a href="https://docs.microsoft.com/en-us/dotnet/api/">.NET API Browser</a>. We've built an entirely new experience to aggregate all code samples that Microsoft ships in the <a href="https://docs.microsoft.com/en-us/samples/browse/">samples browser</a>. And of course I can't neglect mentioning <a href="https://docs.microsoft.com/en-us/learn/">Microsoft Learn</a> — the service that allows anyone around the globe to get skilled in a variety of technologies, entirely for free. Working as part of the team that delivered all this is what I am most proud of.</p><h2>How do you foster collaboration within your team? Any tools or processes that are working really well this year?</h2><p>I am taking a bit of an unorthodox approach here. As someone who worked remotely for the past 4 years, I can confidently say that tools themselves are just that — tools. They don't matter as much as the underlying collaboration culture. You can have fantastic video chat software, but if the culture is not there to work asynchronously, it's not going to help you or your team. One of the things that I try reiterating to my team is that just because we are now not in the office doesn't mean that we need to shift every meeting that we ever had into an online environment. Quite the opposite — this is an opportunity to reevaluate what meetings are really necessary, and where we need to start working offline. It all starts with culture where the team understands the value of not being constantly interrupted by Slack notifications, emails, and Zoom calls. To that extent, to me collaboration means that I show how my team can focus and work when they allocate time for it. I really like the approach that <a href="https://basecamp.com/guides/how-we-communicate">Basecamp</a> is taking here — they are THE company that knows how to do distributed work right. One of the points that stuck with me, that I see a lot of teams fail at, is the fact that communication is not tied to calendars. Way too often we wait for <i>"time to sync" </i>or <i>"discuss during the planning meeting."</i> That's a completely unnecessary roadblock. Why not write a one page document that outlines the pros and cons of an issue, and I will get back with feedback when I have time, if it's not urgent. Or write an email, and I will respond with some thoughts whenever I am not focused on writing the product vision outline. The best way to collaborate is to build enough flex in your process that accounts for everyone's work styles and time allocations. And of course, meetings does not mean collaboration. As a matter of fact, meetings are generally the opposite of that. The more meetings your team has, the more their focus is destroyed. For the love of everything, please stop making everything a meeting and give people space to think through a problem and come up with some thoughtful input.</p><h2>How do you manage prioritization and roadmapping?</h2><p>This will vary between teams, but I like to keep it very simple. The inputs that I look at are:</p><ol><li><strong>Quantitative data.</strong> Do we have any numbers that point us towards the importance of certain things?</li><li><strong>Qualitative data.</strong> Do we have any verbal/written feedback that points us towards the importance of certain things?</li><li><strong>Emerging/established trends. </strong>Are there any specific movements that we see in the space that we need to make sure we are part of?</li><li><strong>Unknown unknowns. </strong>Are there any new opportunities that are not yet understood/seen by others that we can be a part of?</li></ol><p>Once you have reliable data on the above (and getting truly reliable data is hard and is what needs a lot of focus from product managers and their organizations), roadmapping and prioritization becomes easy, because one can clearly see where they can deliver the most value to the customers and the market. Whether it's then put in a JIRA board, or Trello, or whether story points are assigned to each item doesn't matter. The team needs to first understand the <i>"Why"</i> and <i>"What."</i> Everything else comes from these insights.</p><h2>When it comes to product, how do you know when to trust data, and when to trust your intuition? Have you ever taken a risk based on your intuition that paid off?</h2><p>These are not mutually exclusive. You can't rely just on data or just on intuition. It's always a combination, like I called out in the previous question. Anyone that relies exclusively on one or the other is going to either be lucky or wrong. Hard numbers rarely tell you <i>why</i> customers do what they do. Qualitative data coming from user studies only shows you a sample of your total potential customer base. Your intuition can be wrong more often than not because humans are terrible at identifying their own biases. So to mitigate risks, a product manager needs to take the approach where they look at multiple inputs, and then determine a path forward. This is where I am a HUGE proponent of experimentation, which I think is an area that can yield massive benefits to any team. Experimentation enables you to test hypotheses at scale. I'll frame this as an example — say that you are building a site where there is a sign-up flow, and you've noticed that a lot of people are dropping off right before they reach the last screen. Looking at just numbers, you see the drop-off — it doesn't tell you why. A data-savvy product manager or a data scientist might take this a step further and try to look at cohorts — where are the users that are dropping off coming from (e.g. mobile devices, a specific geographic region). This is still an incomplete story. Let's say that the next step is that the sign-up flow is passed through a user study. The product manager teams up with a researcher and they talk to seven people, all of whom went through the sign-up flow. The product manager and the researcher notice a pattern — the users struggle to identify which fields are optional and which are mandatory, and at some point they give up and quit. That's now the basis for a hypothesis — because the data is limited to seven people, it's hard to say if everyone is experiencing the same problem, but the PM intuition tells that <i>"this is likely the blocker."</i> That is not concrete, undeniable evidence. So there are two options for the product manager now. They can go to the engineering team and talk about prioritizing field changes, to make it clearer which are optional and which are required, which would mean some form re-design. If they take this approach, they may solve the problem, or they may make it worse — who knows? Alternatively, the PM can set up an experiment, where they roll out changes to a limited audience to gauge the impact before making a decision.</p><h2>What's your favorite app right now? Why?</h2><p>Safari. I've been spending more time just reading things in the browser on my phone. Modern websites are really well optimized for mobile devices, and in a lot of cases have less negative privacy implications. Other than that, I am a big fan of <a href="https://overcast.fm/">Overcast</a> by Marco Arment. It's a delightful podcast manager.</p><h2>What's the last book or podcast interview that totally wowed you?&nbsp;</h2><p>Probably too many to name — I consider myself to be both an avid reader and a podcast listener, which means that my podcast feed is always overflowing and I have way too many books that I try to read at the same time. The latest book that I've read that really impressed me was <a href="https://www.chapters.indigo.ca/en-ca/books/founders-at-work-stories-of/9781430210788-item.html">Founders at Work</a> by Jessica Livingston. It's an older title (12 years now), but it goes into detail about how certain companies and products were started, and it's fascinating to see how creative founders got with technology that nowadays we take for granted. Truly, constraints breed resourcefulness. From the podcast side of things, I will call out <a href="https://gimletmedia.com/shows/startup">StartUp</a> and its early episodes, where Alex Blumberg talks about creating Gimlet Media from scratch — it really shone a light on how a company is started from an idea to something that people love.</p><p>&nbsp;</p>

Output_Cover_DenCloud.jpg

Output_Header_DenCloud.jpg

An interview with Den Delimarsky

<p>So you’ve got a killer idea for a mobile app or tech product, and you want to build it. But… you don’t know much about design or development. And you're not sure how to launch without a technical cofounder. Sadly, lots of people give up right there. You really don’t have to, though.</p><p>One option: learn to build. Kevin Systrom, founder of Instagram, famously learned to code so he could build the first prototype himself. Cool story, bro. But you’ve probably got a day job and enough on your plate already, so chances are you don’t wanna go that route.</p><p>The other option: get some technical help. For most would-be founders without a technical background, this makes way more sense. It’s rare that one person has both the technical chops and the business acumen to ideate, design, build, launch and market a tech product . So if you’re the non-technical half of the equation, you've got two options. Either you can try to find a technical cofounder, or pay for development help.</p><p>If this is the fork in the road you find yourself at, this article is for you.</p><p>Here at Input Logic, we work with startup founders with all sorts of backgrounds. We’ve helped design and develop a ton of products that might never otherwise have seen the light of day. We’ve learned a thing or two along the way. For this piece, we also spoke with some non-technical founders who’ve actually launched startups. They share their words of wisdom, and advice they wish they’d known when getting started.</p><p>In short, there are five critical things you need to get right:</p><ol><li>Define your problem</li><li>Get to MVP, ASAP</li><li>Develop a brand</li><li>Set a launch strategy</li><li>Bring on a senior technical hire when you’re ready</li></ol><p>Your goal: to get from idea to launch, and onto a successful trajectory.</p><p>We’ll walk you through your options, and some actionable steps you can take to get your startup off the ground.</p><p>Let’s get into it!</p><h2>1. Define your problem</h2><p>This stage is critical. You don’t necessarily need technical help at this point, but you do need outside input. Eric Franzo created and launched <a href="https://www.purposely.ca/">Purposely</a> before bringing on a technical cofounder. This made defining the initial scope a little challenging. “I had too large of an idea,” he told us. “When we ended up bringing a CTO on, he was super good at honing in on the main value. But when I started I had this gargantuan thing.”</p><p>Development work, by nature, requires ruthless prioritization and structured thinking. So someone with a technical orientation can often be really good at helping with problem definition. If you don’t have a technical cofounder, that’s okay. But it’s definitely wise to spend some serious time validating your problem. Talk to potential customers, and people with experience building and setting product strategy.</p><p>Questions you need to answer, with total clarity:</p><ul><li>Who’s your target customer?</li><li>What, precisely, is their problem?</li><li>How are you going to solve it?</li><li>Why is your solution going to be better than anyone else’s? (In other words, what’s your competitive advantage?)</li><li>Who would your competitors be? (If there aren’t any you can think of, why not? There might be a good reason for that.)</li><li>How will you make money?</li><li>Can you validate this idea with real target customers?</li></ul><p>Getting outside perspectives is vital at this stage, before you spend precious time and resources building. Your goal is to zero in on a narrow, precise definition of your target customer, the problem, and your solution. From there, you should have a clear picture of what your business model will be, too.</p><p><a href="http://theleanstartup.com/principles">Plenty has been written about this process</a> so we won’t dive too far into it, but remember: Without a technical cofounder to help you refine your idea and build an MVP plan, it's even more important to get direct, honest feedback from customers and good product strategists.</p><h2>2. Get to MVP, ASAP</h2><p>Whether or not you’re working with a technical cofounder, you’ll want to get an MVP launched as soon as you can. That way, you can start a rapid feedback loop process, where real user behavior helps inform each step of your design and development work.</p><p>The key to developing an MVP is having a crystal clear idea of the problem you’re trying to solve, and for whom (see step 1). Then you need to distill that idea into the most basic version of your product possible. Deciding what not to build at this point is even more important than deciding what to build.</p><p>Another way to think about this: if you knew you only had x number of weeks to make this happen, what would you decide to do for the MVP?</p><h3>Hack it together yourself</h3><p><img src="https://inputwebsite.s3.us-west-2.amazonaws.com/library/giphy_c87ec5a6aa.gif" alt="giphy.gif"></p><p>Maybe you can manually replicate most of the functionality of your ideal product without any technical help whatsoever. Rodolphe Dutel, founder of <a href="https://remotive.io/">Remotive</a>, managed to launch by building a workflow from a combination of SaaS tools.</p><p>Rodolphe was still working full time at Buffer when he started a newsletter about remote work in 2014. Next, he used a basic Typeform and an email-capture one pager to get his remote job board going. For a year and a half, this worked just great. He then built a very basic job board managed by an Airtable, mirrored on a simple HTML page. By the time he added a technical cofounder, Remotive was profitable, and Rodolphe was a few years into running his business.</p><p>The advantage of this approach? It makes you focus. “At the beginning I was highly dependent on other people to help update the website,” Rodolphe says. “I couldn’t have a fancy dashboard, couldn’t handle support tickets. If anyone wanted something from me, I had to think about whether it was feasible for my non-technical-self to do it.”</p><p>Plus, it allowed him to keep costs low while validating the idea. “I didn’t have to think about how to pay for my cofounder’s salary, because that wasn’t feasible at the time,” he told us. Crucially, “having a cofounder would’ve set me on a different path. We would’ve had to sprint to get revenue, or raise money. It wouldn’t have been a community play. I would’ve had to think about revenue and make it profitable ASAP, which wasn’t the objective at the time.”</p><p>Rodolphe was able to build momentum for Remotive before quitting his job, hiring a technical cofounder, and going all in. He did this by validating his idea, hacking tools together, and maintaining ruthless focus early on.</p><p>But what if the type of product you want to build really does need technical help in order to launch?</p><h3>Or hire some help</h3><p><img src="https://inputwebsite.s3.us-west-2.amazonaws.com/library/giphy_2_7fb1d06b8b.gif" alt="giphy_(2).gif"></p><p>If you're looking to hire help to build your product, it’s vital that you pick the right person or team.</p><p>One option is to hire a developer. This is a perfectly viable route, and will usually cost less in the short-term than working with an agency or product studio. It’s important to ask yourself, though: is this person an expert at building the type of product that I’m working on? How well-rounded is their skill-set? Have they built for this particular platform before? Am I still going to need to hire more people to get this off the ground?</p><p>When it comes to working with a product studio, “the downside is the cost,” Eric told us. “But the tradeoff is that you’re getting a lot of expertise and a well-rounded set of voices. You’re getting much more than you would get working with a single person. A lot of that experience shines through. You’re pulling expertise from 5-6 people, whereas a technical cofounder has one experience.”</p><p>A good studio will be able to assist you not just with development, but also design, UX, and product and growth strategy. Even short sprints in each of these areas can radically improve the chances that your product will be successful. They'll get you on a faster path to revenue growth and reduce the amount of development time, effort and investment needed down the road.</p><p>By building a focused scope with a product studio, you can reduce your time to launch and start iterating faster. Having help with product and growth strategy early on means you’re more likely to build the right features first. You’ll also be able to launch with a strong initial customer journey, with the right analytics tracking and testing plan in place.</p><p>And while you don’t want to get too far into the weeds when launching an MVP, some initial UX and UI design can go a long way to helping you build initial traction. You only get one shot at a first impression. A clean, simple, easy-to-use interface will make it way easier to win over those initial customers.</p><h3>Managing costs</h3><p>What about just hiring a handful of third party people from Upwork and manage them yourself? Sure, but remember, that requires a ton of coordination and technical knowledge on your part. Plus, none of these functions happen in a vacuum. UX and growth strategy inform development deliverables. Development constraints inform design. Design informs UX. (And so on, you get the idea.)</p><p>If it’s possible, it might also be tempting to try to skip the cash investment altogether and offer equity to a developer you know in lieu of payment. This can work, if you can find someone great who’s open to it. But you want to be sure that this person is the right one to be building your product. In the end, any percentage of $0 is still $0. Sometimes a better option is to get help from a full-service studio with your MVP, and then bring on development help to iterate from there. Working with one team is often the most cost-effective way to ensure that all these pieces work harmoniously together. You want to avoid redundant work, cost overruns, or multiple stakeholders pulling your project in different directions.</p><p>If you decide to go the product agency / studio route, remember that flashy and fancy is not always better! You want a team that does beautiful work. But you also want them to keep you on track, streamline the work, and help you avoid wasteful detours so you can launch on time.</p><p>If you're interested in working with a product studio but nervous about going all-in, one option is to start with a trial run. You can work with your agency partner on a very limited scope (say, design), which will give you insight into what it'd be like to work together before you invest in the full product build.</p><h2>3. Develop a brand</h2><p>When you’re launching a business, you’ve got to build a brand. That doesn’t just mean ‘design a logo.' A brand is the look, feel and tone of every interaction a customer has with your business, from the product itself right through to their conversations with you and your team. When you’re launching lean and mean, you don’t want to invest an insane amount of time and money here. But remember: intentionally “not having a brand” is still a brand. It’s just not a very good one.</p><p>You can always find a good designer and a copywriter to help you cobble together the basics as a starting point. Better still, if you’re working with a product agency, you can also get them to build some brand identity work into your project plan. The advantage of this? You don’t need to spend time and money trying to coordinate conversations between your designer, writer, and developer. Instead, the studio team will collaborate together and ensure that all the pieces make sense visually, technically and strategically, right from the get-go.</p><p>To keep this phase light and ultra-focused, worry only about the basics:</p><ul><li>A good name (catchy, memorable, marketable, easy to spell and pronounce)</li><li>A logo</li><li>A small color palette</li><li>Basic fonts</li><li>Simple tone of voice (Upscale and serious? Fun and friendly? Edgy and irreverent?)</li><li>A handful of image assets to work with</li></ul><h2>4. Set a launch strategy</h2><p><img src="https://inputwebsite.s3.us-west-2.amazonaws.com/library/giphy_1_ae76537379.gif" alt="giphy_(1).gif"></p><p>This is where the rubber hits the road. It’s a lot of work to build a new product. There’s nothing worse than hitting 'launch' and ... nothing happens.</p><p>The truth is, building up a strong user base almost always takes time. But you can radically shorten the amount of time it takes by being super strategic about what your MVP includes, like we’ve already discussed. And no matter what, you need a good launch strategy.</p><p>What should a launch strategy include? The short answer is: it depends. The longer answer? Even before you spend a dollar on advertising, there are a few things you’ll want to have in place:</p><h3>Momentum already happening</h3><p>For you, that might mean an eager set of alpha or beta users who are already loving your product, providing feedback, and telling everyone they know. It might mean a big email list of people who can’t wait to try it. It might mean one mega-customer who’s excited to get going. What do these things have in common? Planning and preparation well before your launch date.</p><p>At the very beginning when you're validating your problem, find some initial people who are thrilled to try your product. They’re not only valuable for helping you define your product strategy. They’re also the perfect people to solicit feedback from throughout this whole process. Ask them to provide rave reviews before you launch, then use their testimonials everywhere you're promoting your product.</p><h3>The necessary framework to help you grow rapidly</h3><p>Unless you feel like lighting a big pile of cash on fire, you’ll want to have a tight growth loop in place before you launch. What does this mean? At the most basic level, you want to have some clearly defined customer journeys. These should help users get value from your product, get excited, and then share it with someone else. A good product studio or growth marketer will help you bake this into your product strategy.</p><p>What are the key moments that we want a user to get to? When will they get excited? What action can we take to get them to share it with friends, and get value in return? (For example, can they get a discount or a free month for every friend they refer?) This process is different for every product, and usually takes testing over time to really get it right.</p><p>You should plan exactly what these moments are, track them with analytics, and have a testing plan in place to help optimize them in the future.</p><p>The advantage? The better you nail this, the more likely users are to stick around when they first try your product. The more the likely they are to invite friends. The less money, in turn, it’ll cost you to grow your user base. (And the shorter the path to profitability.)</p><h3>Some basic Search Engine Optimization (SEO)</h3><p>You don’t need to go crazy here at the beginning. But be sure that you’re discoverable when people are searching. At very least, be sure that your website (or marketing site, if you’re launching only an app) has the right meta tags and good copy, rich with keywords. A marketer with SEO experience, or a strong product studio, will help you ensure this is all set up properly.</p><h3>If you’re launching an app: think about App Store Optimization (ASO)</h3><p>Whether you’re launching in the iOS App Store, the Google Play Store, or both, there are some simple things you can do to help your app be discoverable. Make sure you’ve got the right keywords in place, use really strong marketing copy, and have clear, compelling images and videos set up tailored to each app store. If you’re selling your app for a fee or if you’ve got In-App Purchases, it’s worth spending some time to configure these properly and clearly communicate why someone would want to pay. Again, a good marketer with ASO experience or a strong product studio will be able to help you out.</p><h2>5. Bring on a senior technical hire when you’re ready</h2><h3>Choosing the timing</h3><p>How do you know when you’re ready to bring on a technical cofounder or executive? For Rodolphe, it was pretty simple. “I had reached the local maximum of what I call ‘being a no-coder.’ Either I could do a community play, which was fine but not what excited me most, or I could find someone who shared my ambition. I was approaching $100K/year in sales, and thought, ‘how to go from $100K - $200K? There was no question about it.”</p><p>If you get external help building your product, you might find that the timing is right pretty quickly post-launch. Eric at Purposely worked with us at Input Logic to build out his MVP, and then brought on a CTO (who he met through friends) shortly thereafter. By that point, the product was launched and ready for iteration and expansion, and he had hired some junior technical staff who needed managing. “The relationship with Input was great,” he says. “When we brought on our CTO they were more than willing to help make that process smooth, and help with the transition.”</p><h3>Finding the right person</h3><p>It’s not easy to find the right technical cofounder. Most non-technical founders we know met their counterparts either working together in the past, or serendipitously through connections. Deciding to bring on a CTO or technical cofounder is a big move, and choosing the right person is critical. (It’s basically like getting married — you’re committing to work closely together for an indefinite amount of time, through the ups and downs of building and growing a business.)</p><p>If you don’t already have strong connections in the tech industry, the process of building your product with hired help or a product studio can help expand your network.</p><p>Even if you launch with SaaS tools and avoid or limit development work altogether, like Rodolphe did with Remotive, you’ll likely find yourself encountering plenty of great technical people on your journey as a startup founder.</p><p>If you haven’t met the right technical cofounder just yet, don’t give up, and don't feel rushed. There are plenty of paths to launch that don’t require you to find the perfect technical cofounder right at the start!</p><h2>Conclusion</h2><p>Launching a successful startup is hard, but even without a technical cofounder it’s absolutely possible. “Be clear about what you want,” says Rodolphe. “Understand what you need. It’s never been easier. Coding is good, but there’s no point using a tank to kill a fly. Remotive is 75-80% commercial, and 20-25% technical. There’s no point to be super heavy in tech when we know it’s a commercial play, with some tech. If you do deep AI, robotics, etc., then sure, have technical cofounders. Else, think about it twice.”</p><p>Sometimes the best route is to get great help, get an MVP launched, and bring on technical talent as you're ready to iterate and grow.</p><p>If you need help, ideally you want to find one trusted group of people who have done this before. Look for people that can help you with:</p><ul><li>problem definition</li><li>roadmap planning</li><li>feature prioritization</li><li>user research</li><li>growth strategy</li><li>brand development</li><li>UI and UX design; and</li><li>your launch!</li></ul><p>Here at Input Logic, this is what we do. If you're looking for help getting your startup off the ground, get in touch below!</p>

Output_Cover_TechincalCofounder.jpg

Output_Header_TechincalCofounder.jpg

How to launch a startup without a technical cofounder

<p>It’s been a year since the introduction of SwiftUI — and if you’re an iOS Developer, now is probably a good time to start considering it as a viable option for building your next app. On its initial release, it was a hard sell to anyone who needed to support older versions of iOS or who didn’t want to deal with the aches and pains of adopting a brand-new framework, even though it offered a graceful, elegant way to build out User Interfaces (UI). But, after giving it some time to mature, and the <a href="https://developer.apple.com/support/app-store/">widespread adoption of iOS</a> 13, SwiftUI deserves a serious look when making your next app.</p><h2>Better UI structure, I do declare!</h2><p><img src="https://inputwebsite.s3.us-west-2.amazonaws.com/library/ezgif_com_optimize_b718208ffe.gif" alt="ezgif.com-optimize.gif"></p><p>Apple has taken a new approach with SwiftUI — offering a declarative solution to building out your User Interface. Traditionally, using UIKit and AutoLayout, we’re used to seeing an imperative approach at building UI.</p><p>If you’re unsure of the difference, think of declarative as telling something <strong>what</strong> to do, and imperative as <strong>how</strong> to do it.</p><p>For example, if I were to hail a cab and tell the driver where I was going taking an imperative approach, I’d say something like, “Accelerate slowly and take the first left turn, drive for 5 minutes and take a right turn on 99 street. Drive for 2 minutes, and stop at building #3905.” With a declarative approach, I’d say, “Go to 3905 99 street”.</p><p>The imperative approach in iOS development often results in complex, hard-to-read files, filled with overloaded, and overridden methods — even for the simplest screens within your app. With SwiftUI, we’re able to build clean UI that’s easy for people to understand even if they aren’t familiar with Swift or iOS development.</p><p>For things like project handoffs and onboarding new developers, this is a huge win. You’re also getting the added benefit of not having to worry about breaking constraints, and ambiguous layouts like you do with AutoLayout. Your layout either works, or it doesn’t.</p><h3>Faster app development</h3><p>Because you’re using a declarative approach with SwiftUI, you write less code, which in-turn means less development time. Animations, transitions, data flow and a host of other things have all been simplified to be easier to digest and implement. Things that used to feel clunky and verbose are now clear and concise.</p><p>On top of this, Xcode includes a Canvas/Live Preview feature for SwiftUI projects which allows you to see UI changes without having to compile an app every single time you want to see changes made in your app. Canvas allows you to see multiple device previews at once, eliminating the time-consuming process of firing up a simulator each time you need to see your UI on a different device.</p><p>No longer do you have to worry about storyboard, .xib files, .nib files, and the headache of Interface Builder — SwiftUI does away with these, providing one simple source of truth. By removing all the complexity surrounding compiling and viewing UI, along with the time saved from writing less code, you’re able to deliver a product a lot faster.</p><h3>Seamless framework integration</h3><p><img src="https://inputwebsite.s3.us-west-2.amazonaws.com/library/swift2_f2ee59644a.jpg" alt="swift2.jpg" srcset="https://inputwebsite.s3.us-west-2.amazonaws.com/library/thumbnail_swift2_f2ee59644a.jpg 245w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/small_swift2_f2ee59644a.jpg 500w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/medium_swift2_f2ee59644a.jpg 750w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/large_swift2_f2ee59644a.jpg 1000w," sizes="100vw"></p><p>Run into something you need from UIKit that isn’t in SwiftUI? No problem! Apple has provided the ability to implement UIKit elements in your SwiftUI project through the use of UIViewRepresentable and UIViewControllerRepresentable protocols. It also works the other way around — you can build SwiftUI views in an existing UIKit project.</p><p>Not only does this provide the flexibility of picking and choosing the best parts of each framework where you see fit, you’re able to minimize the risk associated with switching your project structure and development process. The transition from one framework to another comes with a lot less stress, and is less abrasive than having to choose one or the other.</p><h3>Modern layout options</h3><p>One of the most impressive things about SwiftUI is how the core layout elements operate. Apple has done away with layouts like UITableView, UICollectionView, UIStackView, and replaced them with Stacks and Lists. These components are incredibly flexible, predictable, and require a lot less energy to produce great results. You’re no longer plagued by having to track down broken constraints, worrying if you’ve pinned a child element to its parent improperly, or the gotchas that come along with AutoLayout.</p><p>These components in themselves are quite powerful, but paired with the newest SwiftUI features shown at WWDC2020, the layout system has become even more robust and impressive. Apple has added support for lazy-loading Grid elements, which can adapt the number of columns in a grid to fit the space available, as well as lazy-loading Stack components for building highly-customized, scrollable layouts.</p><p>A lot of these features would be an enormous undertaking if you tried to implement them in UIKit, and it would be hard to match how well they work in SwiftUI. The layout system feels more present-day CSS on the web — it’s modern, responsive, and easily translatable to multiple device sizes and types.</p><h3>It’s only going to get better</h3><p>Going forward, SwiftUI will be the future of development not only for iOS, but all Apple platforms. macOS, watchOS, tvOS all currently support SwiftUI development, and Apple has put a lot of time and effort into it — it’s not going away any time soon. Things like WidgetKit, the API used to develop the all-new widget feature on iOS 14 is currently only being made available to SwiftUI.</p><p>It’s an exciting time to make mobile apps, and with such a rapid progression of SwiftUI in such a short time, the future looks very bright. You can see more of the latest and greatest features that have been added to SwiftUI <a href="https://developer.apple.com/videos/play/wwdc2020/10041/">here</a>.</p>

Output_Cover_SwiftUI.jpg

Output_Header_SwiftUI.jpg

5 Reasons Why iOS Developers Should Switch to SwiftUI

<p>As a branding, packaging, and digital product designer, both at <a href="https://www.inputlogic.ca/">Input Logic</a> and as a <a href="https://lulachristman.com/">freelancer</a>, I work with clients across a wide array of industries, and am responsible for simultaneously getting to the heart of what each client wants and translating those wants into beautiful designs.</p><p>I’ve done my fair share of research on how to best approach new design projects and sprints and there’s a lot out there. What I find is lacking, is about engaging with clients. How can we ask questions to guide their experience and explorations?</p><h3>Not just about how it looks</h3><p>Seeing as we all know that design isn’t just about what looks good, it’s logical that we should emphasize creating meaningful conversations at the beginning of a design sprint so that everyone understands what the intended outcomes are. This sounds like a no-brainer, but once you experience a project riddled with bumpy communication, it makes sense why it’s so important to emphasize information sharing at the very beginning.</p><p><i>Getting to the heart of the product, understanding its’ users, and knowing the client’s vision should always be priorities during a design sprint, no matter the size or scope. As a designer, I find my job is to pull out what the client wants! Sometimes this isn’t always readily available, so we use questions to guide that process of opening up.</i></p><p>The beginning of a sprint is a crucial time, and jump-starting a relationship that values the sharing of these thoughts and opinions will lead to more thoughtful design. Open-ended questions get people talking, and it’s the little details that come out of responses that impact the relationship for the better. This dialogue creates a heightened common understanding, leading to more productive design reviews, followed by the outcome of high-quality design that fits the product. Great conversation early on leads to better design outcomes delivered on time, because everyone starts on the same page.</p><h3>What does the client bring to the table?</h3><p>Clients usually come to a sprint with a strong understanding of their business and position in the market. Our job here is to take in that information and apply our ability to use design to solve problems. This wealth of insight can come to us in many forms:</p><ul><li>Documents</li><li>Moodboards</li><li>Spreadsheets</li><li>Sketches</li><li>Notes</li></ul><p><img src="https://inputwebsite.s3.us-west-2.amazonaws.com/library/brand2_c30ddb0963.png" alt="brand2.png" srcset="https://inputwebsite.s3.us-west-2.amazonaws.com/library/thumbnail_brand2_c30ddb0963.png 245w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/small_brand2_c30ddb0963.png 500w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/medium_brand2_c30ddb0963.png 750w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/large_brand2_c30ddb0963.png 1000w," sizes="100vw"></p><p>Often useful information is tucked away in the clients brain and can be revealed through conversation. Some clients think through many of these questions on their own, while others are prompted by them to find new insights about their product, users, and goals. Translating thoughts and ideas into something coherent can help to expand on ideas that haven’t been explored yet, and work through explaining complex thoughts. It is valuable for everyone involved to understand details, so communication is seamless, and there is a deep understanding of what they’re working on.</p><p>We break up these questions into a few categories: background, the audience, and tone. The more a designer understands these, the stronger the design process will be, and the branding will be enriched with all the right insight. Treating the answers to these questions as though they are for someone who isn’t familiar with the product will also expand the way the questions are answered and may bring up entirely new ideas and thoughts.</p><h3>Background</h3><p>I usually start with questions around the background of the company or product, such as:</p><ul><li>What is the story behind your brand?</li><li>What is your elevator pitch?</li><li>What problem does your product help solve in your space?</li><li>Is there any existing documentation you have that could be used to better understand the market surrounding your brand?</li></ul><p>List 10 words that describe your brand, or the ideal future for your brand (adjectives, nouns, verbs, etc).</p><p>Many of the answers to these open-ended questions might feel redundant by the time a design sprint begins, but insight can be found in the way they are answered. Is the story behind the brand to do with a family member or childhood friend that served as the inspiration? Or maybe the origin came out of first-hand experience or problem, and in turn, the product aims to solve it.</p><p><i>The origin and background of a product is often an area in which many similar products may have something that differentiates them, and these details are often valuable as a piece of reference material when building a brand.</i></p><p>Each product has a unique background, and while some may find an emphasis on the story behind the product, others may see the solving a specific problem as a big part of the story. For example, a brand who’s background is rich in family history might find that this is important to carry this through into the branding, creating a more personal and approachable feel. In exploring these questions, the importance is finding what that emphasis or strength is, and focusing on it.</p><p><img src="https://inputwebsite.s3.us-west-2.amazonaws.com/library/brand_f08abf2cce.png" alt="brand.png" srcset="https://inputwebsite.s3.us-west-2.amazonaws.com/library/thumbnail_brand_f08abf2cce.png 208w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/small_brand_f08abf2cce.png 500w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/medium_brand_f08abf2cce.png 750w," sizes="100vw"></p><h3>Audience</h3><p>Once I understand the background and story behind a company, I start to ask questions about their target market:</p><ul><li>Who is your brand for? Describe your customer.</li><li>How do people find out about your brand?</li><li>What features or benefits does this identified target audience seek that your product is offering?</li></ul><p><br>Understanding the customer is very important, as we all know. In some cases, maybe the client belongs to their target demographic, making it easy for them to understand their customer. In other situations, it might take some exploration to identify who the target customers are. This can take many forms — from examining competitors customers to diving deep into the product and it’s features to identify who would be likely to use it. This is crucial to building a visual identity, as it creates a high level of empathy and understanding for when, why, and how a user might interact with the product.</p><p>On top of identifying the target audience, It’s also crucial to understand some of the more subtle interactions that these people have surrounding the brand. While a lot of insight into the customer base comes from research in the form of interviews, testing, focus groups and surveys, it’s still beneficial to identify if anyone out there has published research surrounding the identified target market segment. Having a general understanding is a great place to start, and will help aid the design process to be on track with the right look and feel for the intended customer.</p><h3>Tone</h3><p>Once I understand the background and audience, then I like to dig into the tone and voice the customer expects:</p><ul><li>What existing brands are similar to yours in spirit (doesn’t need to be the same industry). Describe the connection.</li><li>What feeling do you get when you think about your brand?</li><li>What do you want people to understand, feel, or believe about your product?</li><li>If your brand was a period or era, when would it be &amp; why?<br>&nbsp;</li></ul><p>Many things influence the tone or attitude of the brand, including the background and audience. Often, the intended customer might expect a certain voice or feeling from the product, while others might be more open or even expect something different. In terms of the design process, the tone is one of the most crucial portions of research that influences design, which can come in the form of visual appearance or even microcopy. In many cases, we see a lot of value in hiring a copywriter who is experienced with the target market. For example, if the voice of the product is youthful, fresh, and innovative, this has a direct influence on things such as colour, and typography, as well as the type of vocabulary that is used when communicating.</p><h3>The value of open-ended questions</h3><p>Open-ended questions bring up a myriad of different response types, which is what makes them so valuable for gaining insight. Answers could come in the form of a story, documentation, keywords, concise explanations, or even conceptual feelings that the product aims to communicate. While some questions might take some time to answer and clients will benefit from having time to think through them independently, it’s also important to use them as a tool for conversation, let them naturally flow, and engage with the responses. Most importantly, take notes! Having this valuable insight is a great resource to come back to later.</p><h3>Putting it into practice</h3><p>Identifying actionable steps is great, but putting them into practice is better. How can these questions be put into use? However they’re applied, whether in a survey before the kickoff call, or brought up naturally in conversation, we must use them to create dialogue, rather than an interview-style where we simply ask, answer, and move on to the next question. Refer to them during a kickoff call at the beginning of a project, use them as a guide for conversation, and create a dialogue around them. These questions can and should be used as a tool for designers and project managers to gain insight into the client’s perspective and vision, as well as for the clients to communicate their expectations.</p><h3>In Closing</h3><p>Want to learn more about how we approach branding engagements at Input Logic? Reach out below!</p>

Output_Cover_AskingQuestions.jpg

Output_Header_AskingQuestions.jpg

Getting the most out of your branding sprint with open-ended questions

<p>Launching an app is an exciting business endeavour but is also rife with tough decisions; many of which can quickly derail progress and send you into a financial tail spin.</p><p>One such decision is the technology or platform on which to build. While there are only really two players for mobile operating systems, iOS and Android, there are an array of choices on how to build upon them. This is a common question from our clients and one we encourage them not to take lightly.</p><p>In this article I’ll outline 4 major options with pros and cons of each. By the end, you’ll be ready to make an educated decision about which platform to build your app on.</p><h3>The 4 mobile platforms</h3><p>While there are technically more than 4 options out there, these are the leaders from which we choose time and time again. Each offers its own unique benefits (and pitfalls).</p><h3>Platform specific (aka: Native)</h3><p>Developing for each OS (operating system) in its native language is of course the most supported and most performant. It’s also the most expensive. This is because you’ll be writing the app in a separate language for each. The two players are iOS (written in Swift or Objective-C) and Android (written in Java or Kotlin). While there are developers that can code in both, you’re much more likely to end up hiring one for each, doubling your overhead. Native apps are the best choice when they have high performance or memory requirements, OS specific libraries not supported elsewhere or games.</p><p><strong>Key takeaways:</strong></p><p>👍 Most performant</p><p>👍 Best support for leveraging hardware functionality</p><p>👎 Most expensive</p><h3>React Native</h3><p>React Native (often abbreviated as RN) is a popular choice and is sort of a blend between Native and “Web”. The majority of the code written is shared across both iOS and Android with a few select cases when handling functionality specific to each operating system. This results in a significant reduction in cost and timeline. Because React Native is written in Javascript, it can quickly become unwieldy and hard to debug if not managed by experienced developers. Shooting yourself in the foot is amazingly easy. Still, with the right team, RN is a fantastic choice and one we use often.</p><p><strong>Key takeaways:</strong></p><p>👍 Majority of code is re-used across both OS’s</p><p>👍 Significant cost and time savings</p><p>👎 Hard to debug, easy to shoot yourself in the foot</p><h3>PWA</h3><p>Progressive Web Apps (PWA’s) are exactly what they sound like; apps that work via the web. Instead of installing the app on your phone from the App Store, you can access them via the browser on your phone. This has some significant advantages. The biggest is the ability to use stable and well known web languages with 100% code sharing. There are a few drawbacks however. Most notably you won’t be able to install the app from the app store and offline capabilities are very limited with iOS (Android has full support). We often use PWA’s when timelines and budgets are a concern or when a client is still validating the concept with a basic offering (also known as a MVP).</p><p>It should be noted there are ways of wrapping a PWA in a Native “shell” in order to install on the App Store or use hardware functionality. In these cases, we believe using React Native is a better choice than wrapping the PWA.</p><p><strong>Key takeaways:</strong></p><p>👍 Works on all devices with a single code base</p><p>👍 By far the cheapest</p><p>👎 No App Store, limited functionality and offline capabilities</p><h3>NoCode</h3><p>The #NoCode movement is relatively new to the industry and is a way of using other existing tools to “mashup” an app by piecing them together in interesting ways. As the name implies, there is no (or very little) coding involved. Each of the tools you use will have their own monthly licensing fee, which can add up quickly. We like to use NoCode for proof of concepts or when building tools for a client that will be used internally. A good example might be a an inventory tracking system for a shipping and receiving company. More often than not however, these are quickly outgrown and a custom app is developed.</p><p><strong>Key takeaways:</strong></p><p>👍 Fastest way to market</p><p>👍 New options popping up daily</p><p>👎 Monthly licensing can get expensive quickly, outgrown quickly</p><h3>Where to go from here</h3><p>When choosing a platform its important to ask a few questions:</p><ol><li>What is your budget?</li><li>What is your timeline?</li><li>Does the app need to work on iOS, Android or both?</li><li>Does the app need offline capabilities?</li><li>Will the app require hardware functionality such as GPS or Bluetooth?<br>&nbsp;</li></ol><p>If you have a tight timeline and budget, going with a hybrid approach using React Native or PWA is probably your best bet. If you have a bit of budget, hardware requirements and need it to run on both OS’s, React Native is a good choice. If you have specific hardware requirements not supported by other tools or high performance requirements then Native is basically your only option.</p><p>Hopefully after all that you have a better understanding of how to choose the best platform for your app. Its important to remember that, regardless of what you choose, you can always change it later. Yes sometimes that can be more expensive, but not launching at all or choosing the wrong platform to start will stop you before you even get started.</p>

Output_Cover_Choosing.jpg

Output_Header_Choosing.jpg

How to choose a platform for your mobile app

<p>React Native has become increasingly popular since its initial release in 2015, and it’s easy to see why. It’s become a well-supported, well-maintained solution to building cross-platform apps, and I’ve spent most of my time doing just that with the team at Input Logic. Before using React Native at Input Logic, we produced all our mobile applications through native code — Swift, Kotlin, Java — and while native applications are still a perfect solution in many instances, React Native has allowed us to ship cross-platform apps for clients for around 60% of the cost of going pure native. It’s helped me to provide clients with solutions that perform well and cut down our development time — which make a big difference for our team and our clients.</p><p>In this post, I’ll share some of my experience and tips for using React Native to help you figure out if it’s right for your next project.</p><h2>Why React Native?</h2><p>If you have a project or a business — especially a startup — React Native is a great way to get everything up-and-running quickly. It’s a fantastic tool for rapid prototyping, due to the nature of how React works — everything is designed in components, and with a single update to a component, you can see changes reflected across every screen in your app. You can develop applications for multiple platforms that share the same code base, and you get to skip out on some of the more tedious native code that differs between iOS and Android. As a developer, you don’t have to face the monotonous task of constantly rebuilding your application to see changes, with React Native’s hot reloading feature providing quick — almost instant — feedback as you build out your features.</p><p>Looking past the time-saving benefits, it’s important to note that you can build React Native apps with basically every feature that would be offered in a native application. I’ve either tested or implemented push notifications, geo-fencing, messaging, analytics, event tracking, biometrics authentication, offline modes, and social login, just to name a few. Apps that we’ve built or worked on at Input have also been met with largely positive feedback from users, showing ratings higher than ⅘ stars for each, with minimal complaints or crashes.</p><p><img src="https://inputwebsite.s3.us-west-2.amazonaws.com/library/react2_6fb6353732.png" alt="react2.png" srcset="https://inputwebsite.s3.us-west-2.amazonaws.com/library/thumbnail_react2_6fb6353732.png 174w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/small_react2_6fb6353732.png 500w," sizes="100vw"></p><h2>Before You Start</h2><h3>Is React Native right for your project?</h3><p>While there are a number of benefits to using React Native for most applications, there are always cases where it just makes more sense to build a regular native app. Before deciding what’s going to work for you, it may be beneficial to ask yourself the following questions:</p><ul><li>Do I need any resource-heavy or complex 3rd party tools or SDKs?</li><li>Do I need to develop for both Android and iOS?</li><li>How many native features do I need?</li></ul><p>Based off of how you answer these questions, you can start to get an idea of whether it makes more sense for you to build an app natively or if you should move forward with React Native.</p><p>For example, as a developer, if you need a feature-rich application where you’re going to have to code a multitude of native features just to work with React Native, your time may be better spent building everything natively.</p><h3>React Native != Web</h3><p>Often, people without any exposure to React Native have the idea that it’s a WebView that renders HTML and CSS, similar to other mobile solutions built on top of Apache Cordova — which is not the case. React Native is real native development, it does not manipulate the DOM, but rather utilizes multiple threads to bridge native code, render native components, and run your JavaScript. There are also plenty of ways React Native differs from web:</p><ul><li>While styling does have a camel-case CSS syntax, in many instances it won’t behave as it does on the web.</li><li>Animation is not handled through transforms or keyframes, but rather an API which behaves much differently</li><li>Shadows are implemented differently</li><li>Media queries do not exist</li><li>Flexbox only</li></ul><h3>Understanding Native Development</h3><p>Going through a project without ever having to touch native code is highly unlikely, and at some point you’re going to have to use it.</p><p>While you don’t have to be an expert in these native programming languages, you should have a basic understanding of how each platform works. Be prepared to add tablet support, splash screens or other things you may not think you need right now, but may in the future due to changes in circumstance, scope, or feedback.</p><p>It’s also very valuable to learn how React Native module linking works. Often, it’s handy to know not only how to manually link a native module, but how to build, edit, and bridge native code if you need to. There will inevitably come a time when a client wants to use a 3rd party tool, and that tool does not have a React Native wrapper.</p><h3>Advice From My Experience</h3><p>Just like with React, React Native projects can be built in a wide variety of ways. I’m not here to tell you what works best, as this is largely based on how your team works together. Find a way to build things your whole team can get on board with, and stick to it. Keep things clear, and standardize your approach throughout your app. Keep in mind that boilerplate or auto-generated skeleton projects sometimes come with extra complexity you might not need or may be confusing as you move through your project.</p><p><img src="https://inputwebsite.s3.us-west-2.amazonaws.com/library/react3_1_674b5a0e80.png" alt="react3-1.png" srcset="https://inputwebsite.s3.us-west-2.amazonaws.com/library/thumbnail_react3_1_674b5a0e80.png 245w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/small_react3_1_674b5a0e80.png 500w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/medium_react3_1_674b5a0e80.png 750w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/large_react3_1_674b5a0e80.png 1000w," sizes="100vw"></p><h3>Use the APIs, Luke</h3><p>React Native is filled with built-in functionality and features out of the box, and it’s important to check what is available to you through the API.</p><p>The Platform API can help you with Platform specific code, as can the global `__DEV__` variable. Even text input components have helpful properties like character limit, keyboard appearance, and a host of other things that you might not notice until you read the documentation.</p><p>There are also a wide-variety of features outside the UI so it’s worth checking out the docs before you decide to go build your own functionality.</p><h3>Upgrading React Native</h3><p>Upgrading React Native can be taxing if left for too long, and sometimes the solutions provided just don’t seem to work, have too many conflicts, and can cause you a world of pain.</p><p>I’ve found the best approach to updates is to do them incrementally, based on what was changed from version-to-version. At Input, we often reference rn-diff so we know what to expect, while using npm-check-updates for updating our node modules. It’s also helpful to check the changelog between versions to see what improvements or new standards have been set forth (ex. upgrading from List to FlatList).</p><h3>Versioning and Data Persistence</h3><p>If you’re using something to persist your application state like redux-persist, use semantic versioning, or a method of determining whether persisted data is compatible with your new app version, and have some kind of fallback in the event it’s not. While your application may not crash in development after changing your state object, or whatever data you’ve chosen to persist, a user who is multiple versions behind and chooses to update their app may not have the same experience.</p><h3>Navigation</h3><p>This is probably one of biggest issues people face when dealing with React Native. I’ve had the chance to use multiple different navigation libraries, and up to this point feel as though react-navigation is the most suitable to my needs. It’s important to plan out how to organize your navigators, and be mindful of what components are being mounted and when. Too many nested navigators can result in many screen components being mounted at the same time, and it’s possible that you can run into memory issues if you’ve got things running in the background.</p><h3>Libraries for React Native</h3><p>I’ve found a few libraries helpful after exploring and testing different options. Below is a list of options I’ve found advantageous to my workflow, and why I chose them.</p><p><a href="https://github.com/invertase/react-native-firebase">react-native-firebase</a> — There are a few options out there for dealing with mobile push notifications, but I found this library to be the simplest to use. I’ve had to use other 3rd party solutions upon client request, but they all used firebase in one way or another for Android notifications. Using firebase as a solution for both platforms takes out a few extra steps, and reduces complexity.</p><p><a href="https://github.com/tipsi/tipsi-stripe">tipsi-stripe</a> — This is a great choice if your app uses or receives payments with stripe. It’s easy setup, and has built-in interfaces for handling credit card information if you don’t want to code your own screens and validation. You also have access to G pay and Apple Pay, and the library has improved greatly over the past year or so.</p><p><a href="https://github.com/date-fns/date-fns">date-fns</a> — Simple, and lightweight compared to some of the other date libraries out there.</p><p><a href="https://github.com/react-native-community/react-native-svg">react-native-svg</a> — A great library for using SVGs in your app, and was especially helpful when implementing custom map markers with <a href="https://github.com/react-native-community/react-native-maps">react-native-maps</a>.</p><h3>Other Considerations</h3><ul><li>Be careful with performing side effects in component lifecycle methods, as large tasks can cause slowdowns in your app.</li><li>Watch out for outdated advice or articles written about React Native. The framework has evolved rapidly over the last few years and the solution may no longer be accurate.</li><li>Build both platforms at the same time, test on both frequently — Styling isn’t perfect between each platform, and there will be differences in positioning, text size, etc. Occasionally there can be differences in the JS core which may cause unwanted behavior on one platform.</li><li>Test on physical devices, emulators don’t always behave the same as an actual phone, and some features may not even be available.</li></ul><h2>Final Thoughts</h2><p>Overall, my experience has been overwhelmingly positive with React Native, and I’ll likely continue to use it for future projects. It provides a substantial amount of built-in functionality, and once you’ve established a workflow, and your team has developed a solid understanding on how to approach new features and functionality, it can be a very effective way to build highly successful and polished mobile applications.</p><p>&nbsp;</p>

Output_Cover_React.jpg

Output_Header_React.jpg

What I’ve Learned Building 4 React Native Apps Over 3 Years

<p>We build a lot with Django. It’s one of our favorite frameworks, along with Flask, Rails and Phoenix.</p><p>A common headache of any new project is prepping for local dev, production configs, and sane test integrations.</p><p>To help solve this, we create “starter projects”. They’re hosted on GitHub. To use them, simply fork the project and get to work.</p><p>Today, I’d like to share our Django Starter project.</p><p><a href="https://github.com/inputlogic/django-api-starter">You can find the GitHub repo here</a>.</p><h2>Local dev</h2><p>First out the gate is local development. How do we run the project? Virtualenv? Vagrant? Docker? Which is our default database and what are the credentials?</p><p>We prefer to use <a href="https://virtualenv.pypa.io/en/stable/">Virtualenv</a>. We like its support for both Python 2 and 3 and is much simpler than Vagrant or Docker. Python 3’s venv is cool but isn’t backwards compatible.</p><p>For our database, we use Postgres. That simply comes down to team familiarity and that we like to use Heroku for almost all deployments. Each database is named after the project and everyone has a postgres superuser that can create and migrate tables. With this approach, the local file can be identical across all workstations and makes sharing dev credentials much easier.</p><h2>File structure</h2><h3 style="margin-left:0px;">Apps</h3><p>There are a few methods for organizing Django. The most common two are having Django apps at the root level or within an apps/ subdirectory. We prefer the latter.</p><p>There are two reasons for this:</p><p>It makes the top level structure much easier to read and traverse</p><p>It helps decouple app specific logic from other “general” modules</p><p>Each app also contains all of its own logic, including tests. Some teams prefer to have a dedicated tests directory. Our approach is to keep each area of functionality nicely encapsulated. If you’re working on that area of the project, theres only one place to look. No surprises.</p><p>Here’s a quick example:</p><p><code>apps/</code><br><code>someapp/</code><br><code>&nbsp;views.py</code><br><code>&nbsp;tests.py</code><br><code>&nbsp;...</code><br><code>libs/</code><br><code>filters.py</code><br><code>...</code><br><code>project/</code><br><code>settings/</code><br><code>&nbsp;common.py</code><br><code>&nbsp;local.py</code><br><code>&nbsp;production.py</code></p><h4>Settings</h4><p>The default settings.py file is broken into a settings/ subdirectory with common (global) configs and environment specific configs. This aids in local development and production specifics while sharing common configs across both. Without this, the standard settings file quickly becomes unwieldily and hard to read.</p><h4>Libs</h4><p>Anything that isn’t specific to an app should go into the root libs directory. This is typically where we’d have custom modules for handling template helpers, project (not app) specific logic, etc.</p><p>For the most part, each bit of functionality is put in one file. One exception to this is template filters, where all of them exist in one.</p><h3>Logging</h3><p>Logging is notoriously difficult to get right in Python and Django. Due to this, we wanted to have a standard that would work across local as well as production.</p><p>Our logging configuration is specified in the “common” config file and addresses each area of the project including Django itself, apps and celery tasks. Having each broken into their own setup allows us to easily dial up the logs in different areas while completely hiding them in others.</p><p>This has a few beneficial side effects:</p><p>Common logging formats across all our projects, making it easier to scan logs when debugging</p><p>Developers are less inclined to use print statements because they can’t get the log to work</p><p>Log output can be updated in a single location, whether we want to stream to stdout or a 3rd party service like Papertrail</p><h3>Worker queues</h3><p>Not all our projects require background jobs, but we decided to include some examples since not everyone is familiar with the setup.</p><p>Our preferred tools are Celery and RabbitMQ. When these aren’t used in the project, we simply delete the related celery and task files.</p><p>Worker queues are typically used for batch processing. This might be image resizing, bulk emails, Twilio text messages or multi-chain API calls.</p><p>Because we use Heroku, spinning up a fleet of workers becomes a trivial step instead of spending unecessary time configuring containers or EC2 instances. Just update the Procfile and you’re good to go.</p><h3>Testing</h3><p>We like to keep tests simple and focused. If you need to start testing your tests, you’ve gone too far.</p><p>We use the default Python unittest along with Django’s TestCase suite. FactoryBoy and <a href="We use the default Python unittest along with Django’s TestCase suite. FactoryBoy and Faker are used for simplifying test data.">Faker</a> are used for simplifying test data.</p><p>Lastly, we use TravisCI for running tests against our pull requests, which helps keep our development cycle tight.</p><h3>Production</h3><p>Our preferred method of production is to use Heroku. To that end, we include a default Procfile which includes the common patterns for web and worker dynos.</p><p>After a bit of environment config housekeeping, deployment is as easy as</p><p><code>git push heroku master</code></p><p>When it comes time to hand-off the project to our clients, transferring ownership is instant and doesn’t require any changes. Whats not to like?</p><h3>Future plans</h3><p>When it comes time to hand-off the project to our clients, transferring ownership is instant and doesn’t require any changes. Whats not to like?</p><p>At the moment we reach for React first. We’re thinking of either adding some NPM build scripts and examples to the project itself or a dedicated React starter project that can be dropped into any of the framework starters we make.</p><p>We also plan to creating some starter projects for Phoenix and Flask.</p>

Output_Cover_Django.jpg

Output_Header_Django.jpg

Starting your Django project on the right foot

<p>During my 7 years as a freelance user interface designer, I complimented an older and wiser client of mine who ran his own agency on how smoothly the projects went that he hired me for. In reply, he shared a nugget that’s stuck with me for years.</p><p><strong>“Managing projects is all about managing people’s expectations.”</strong></p><p><i>~ John Edmonds, Voice of the Cadbury™ easter bunny</i></p><p>It’s with this nugget in mind that I’m writing a brief article on what to expect before working with our team at Input.</p><h2>A little context</h2><p>If you’re reading this it’s likely you’ve received a link to this article or discovered it on Medium. Chances are, we haven’t had a call yet but we’ve been introduced. Originally I meant to share this privately with potential clients, but I thought sharing it publicly would be interesting to others in my industry and help us to continue</p><h2>Step 1 — 👋🏽 Intro</h2><p>Most people come to us through intros. Every intro leads to a scheduled Google Hangout where we digitally shake hands and cover the basics:</p><h3>The story behind Input</h3><p>How we got started, our specialties, products we’ve built, our process</p><p>The story behind your app or idea</p><p>How you got started, your vision, how your team works</p><h3>The broad scope of your vision</h3><p>A description of your project including platform and features</p><h3>A rough budget and timeline</h3><p>A ballpark timeline and dollar amount to get it done</p><p>We work collaboratively with all our clients so we try to avoid “big reveals”. That means we show you our work-in-progress like we’re on the same team. We’ll get your feedback every step of the way, and that includes during the budgeting phase. We’re not a big agency who will book a board room to “present” our work. We’re more likely to ping you on Slack with a link to an Invision board or a staging site and talk things in real time.</p><p>If we’re all feeling like a good fit after the intro call, we’ll schedule a scoping session to get into the nuts and bolts.</p><h2>Step 2 — 🕵🏼 Scoping session</h2><p>This is where we hash out a detailed project scope in an effort to produce an accurate budget and timeline. In contrast to the intro call which is 1-on-1, we bring a project manager and any relevant team members into the scoping session and we invite you to do the same.</p><p>In the scoping session we:</p><h3>Create an object map of your product</h3><p>User profiles, ride shares, dates, recipes, you name it — we flesh out the myriad of features or objects that make up your product</p><h3>Determine our level of involvement</h3><p>With each feature in mind, we figure out if you need a hand with design, front-end, API, backend, mobile, or all of the above</p><p>Once we know what needs to be created and which parts we can help with, we commit to getting you a budget and timeline within a few days, and we schedule a call to review it.</p><h2>Step 3 — ⏰ Scope, budget &amp; timeline</h2><p>With a clear picture of your goals, we create a detailed timeline, budget, and project scope, and then email it to you a day or two before our scheduled review call. This gives you time to share it with colleagues, look it over, and do any additional research you’d like to before we chat about it.</p><h2>Step 4 — 🤔 Review</h2><p>After you’ve had time to look over the budget and timeline, we simply talk through it. Any concerns? Any changes? Sure, let’s work it out. We aim to be part of your team, so let’s nail down how to get together in a way that works for everyone.</p><p>No changes? Let’s get an agreement in place and kick things off.</p><h2>Step 5 — 🖋 Agreement</h2><p>Once everyone is on the same page, we write it all up in our standard agreement and send it over for signing! Then all that’s left is to schedule a start date and make sweet magic together.</p><p>Hopefully this has been a helpful little preview into the steps we take before working together. Can’t wait to get started!</p><p>&nbsp;</p>

Output_Cover_Sales.jpg

Output_Header_Sales.jpg

What happens after the intro?

<p>It was a rainy winter day and I was having another project management crisis with my business partner Gavin at our digital product studio Input Logic. The exact nature of the crisis eludes me now, but I’m sure we’d let some client expectations slip and were feeling guilty again.</p><p>We’d been making awesome apps for years now, but always just barely stumbled through project management. We pissed off clients and burned bridges, even though we were proud of the work itself.</p><h2>We needed a change</h2><p>Upstairs in the startup lounge at the co-working space we occupy I proclaimed, “That’s it, we have to become experts at project management.” I was determined.</p><p>Gavin paused a long time and finally sighed, “We’ve been saying that for 10 years man... Maybe it’s time to admit that we suck at project management and just hire someone?”</p><p>He was right.</p><p>A project manager would be the first person on our team who wasn’t explicitly being paid to produce something — code, product designs or animation. The stuff people pay us for. What would a PM do really? Make sure we get back to our clients on time? Make coffee?</p><p>We had no idea how to do project management, but we knew we needed it. We hired a project manager named Brandon who we knew our clients would love, and then hired Rachel to train us all. Six months later, we’ve developed some great processes that fit with our culture, our projects are on time, and our clients are happier. We’re still digging deep to create more efficient processes, but we can confidently say that the experience our clients have working with us now is as good as the products we produce. This has been a goal of ours for some time.</p><h2>Using Slack</h2><p>Our team of eight is pretty playful. We don’t take ourselves too seriously. We level up our abilities, play hackysack, and ship great work. We wanted a project management process that was in line with our values: relevant and helpful without sucking the fun out of things.</p><p>After some experimenting, we settled on using Slack as our primary project management tool through these simple practices.</p><h2>Practice #1 — Project based channels</h2><p>We create a separate channel for every project, period. We invite only those team members who are involved in the project, along with the project manager.</p><figure class="image"><img src="https://inputwebsite.s3.us-west-2.amazonaws.com/library/process2_98d5d29db5.png" alt="process2.png" srcset="https://inputwebsite.s3.us-west-2.amazonaws.com/library/thumbnail_process2_98d5d29db5.png 245w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/small_process2_98d5d29db5.png 500w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/medium_process2_98d5d29db5.png 750w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/large_process2_98d5d29db5.png 1000w," sizes="100vw"><figcaption><span style="color:rgb(117,117,117);">We create individual Slack channels for every client project.</span></figcaption></figure><p>These are multi-disciplinary channels containing coders, animators and designers alike, but no clients. We use these channels internally to discuss the project and keep it on track. Often we will create a separate channel that we invite the client to as well.</p><p>Every day, we keep a running dialog about each project in it’s respective channel. We share documents, links, and feedback publicly in the channel instead of privately between teammates. This keeps everybody up to speed on any changes in direction without losing information to private conversations.</p><h2>Practice #2—Agreements pinned to project channels</h2><p>Our client agreements are separated into a general agreement and a statement of work. We create them in Google Docs and then export them as PDF to be shared in Slack.</p><figure class="image"><img src="https://inputwebsite.s3.us-west-2.amazonaws.com/library/process3_95846b7912.png" alt="process3.png" srcset="https://inputwebsite.s3.us-west-2.amazonaws.com/library/thumbnail_process3_95846b7912.png 226w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/small_process3_95846b7912.png 500w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/medium_process3_95846b7912.png 750w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/large_process3_95846b7912.png 1000w," sizes="100vw"><figcaption><span style="color:rgb(117,117,117);">On the right you can see the pinned project scope, wireframes, and prototype.</span></figcaption></figure><p>We pin the contract PDF to each project channel even before divvying up tasks between team members, so every person knows what the team is contractually bound to do.</p><h2>Practice #3—Live timeline as project channel description</h2><p>We started using TeamGantt for creating project timelines and we share these with our team and the clients team. We detail out the intended timeline right from the start, so we have the same expectations the client does. Each team member working on the project offers input into the creation of the timeline and we make changes as meetings and milestones move so it’s always accurate.</p><figure class="image"><img src="https://inputwebsite.s3.us-west-2.amazonaws.com/library/process4_79664bb2fd.png" alt="process4.png" srcset="https://inputwebsite.s3.us-west-2.amazonaws.com/library/thumbnail_process4_79664bb2fd.png 245w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/small_process4_79664bb2fd.png 500w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/medium_process4_79664bb2fd.png 750w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/large_process4_79664bb2fd.png 1000w," sizes="100vw"><figcaption>An example of a project timeline created with TeamGantt.</figcaption></figure><p>The full gantt chart style timeline is added as the description of every project channel in Slack, and our project manager Brandon updates the timeline with changes due to delays on our side or the clients.</p><figure class="image"><img src="https://inputwebsite.s3.us-west-2.amazonaws.com/library/process5_3cf0d7534c.png" alt="process5.png" srcset="https://inputwebsite.s3.us-west-2.amazonaws.com/library/thumbnail_process5_3cf0d7534c.png 245w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/small_process5_3cf0d7534c.png 500w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/medium_process5_3cf0d7534c.png 750w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/large_process5_3cf0d7534c.png 1000w," sizes="100vw"><figcaption>The channel description under #ubora is a link to the project timeline.</figcaption></figure><p>Everyone has quick access to the live timeline so every teammate on the project knows when the high level deliverables are due.</p><h2>Practice #4—Post weekly plan in #general channel</h2><p>So far, every teammate now has access to specific project channels in Slack, an understanding of the contractual scope of their projects, and the entire timeline. Now we get a little more nitty gritty.</p><figure class="image"><img src="https://inputwebsite.s3.us-west-2.amazonaws.com/library/process6_c1c45c07e2.png" alt="process6.png" srcset="https://inputwebsite.s3.us-west-2.amazonaws.com/library/thumbnail_process6_c1c45c07e2.png 226w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/small_process6_c1c45c07e2.png 500w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/medium_process6_c1c45c07e2.png 750w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/large_process6_c1c45c07e2.png 1000w," sizes="100vw"><figcaption>An example of our weekly plan post in Slack each week.</figcaption></figure><p>We create a new Slack post every week and pin it to the #general channel, replacing the post from the previous week. It outlines our goals as a team, and each individuals overarching goal for the week.</p><figure class="image"><img src="https://inputwebsite.s3.us-west-2.amazonaws.com/library/process7_dbdbdade54.png" alt="process7.png" srcset="https://inputwebsite.s3.us-west-2.amazonaws.com/library/thumbnail_process7_dbdbdade54.png 245w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/small_process7_dbdbdade54.png 500w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/medium_process7_dbdbdade54.png 750w,https://inputwebsite.s3.us-west-2.amazonaws.com/library/large_process7_dbdbdade54.png 1000w," sizes="100vw"><figcaption>We pin the weekly plan to our teams #general channel.</figcaption></figure><p>We create this document during an 11am face-to-face meeting every Friday, so on Monday morning people fire up their laptops they know exactly what to focus on.</p><h2>Practice #5—Integrate Trello with Slack</h2><p>This article is about Slack, so I won’t get too far into how we manage individual tasks in Trello, but I do want to highlight the awesome Slack integration in Trello for Business.</p><p>You can remind teammates in Slack about Trello card due dates, share Trello cards in Slack conversations, and even connect boards to project specific Slack channels. Definitely worth checking out for a Slack based workflow.</p><h2>How it all came together</h2><p>So, after years of occasionally pissing off clients with sloppy project management, we’ve levelled up our game with a few simple Slack based practices. Pretty dope.</p><p>We're still working to improve and learning a ton, so stay tuned for more!</p>

Subscribe