<p>This is part two of our new series, <a href="https://www.inputlogic.ca/tag/product-thinking" target="_blank">Product Thinking</a>. 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" target="_blank">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 src="https://inputlogic-develop.s3.amazonaws.com/input-logic-website/andrew-profile-roof-resize.jpg.jpeg"></p><h2><strong>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?</strong></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><strong>How did you get started?</strong></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><strong>Cool. How’d you learn to code, and what was your journey into product?</strong></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><strong>Do you still code? Is it useful as a PM?</strong></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><strong>Can you tell us more about what you’ve been working on with the Biden campaign?</strong></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><strong>So you’re really in the thick of it!</strong></h2><p>Yeah. I mean, it was all hands on deck for seven days a week for a couple of weeks.</p><h2><strong>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?</strong></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><strong>How did you end up joining the Biden campaign?</strong></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><strong>Awesome! Do you have advice for people who want to engage more on Twitter? How do they start taking advantage of it?</strong></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" target="_blank">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/" target="_blank">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><strong>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?</strong></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><strong>When you’re hiring and trying to fill a skill gap of your own, how do you choose the right person?</strong></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><strong>Definitely! So, circling back to LinkedIn, what’s something you worked on that you’re really proud of?</strong></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><strong>What was the biggest challenge you faced in doing that?</strong></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><strong>Definitely. When it comes to making product decisions, how do you know when to trust data and when to trust your intuition?</strong></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><strong>What’s your favorite app right now, and why?</strong></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><strong>If someone wanted to get started in product and they were just beginning their career, what would you suggest they do next?</strong></h2><p>I’d say, start by watching as many <a href="https://www.youtube.com/channel/UC6hlQ0x6kPbAGjYkoz53cvA" target="_blank">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><em>To hear more from Andrew, check out his </em><a href="https://andrewyu.substack.com/)" target="_blank"><em>Substack</em></a><em>. 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.</em></p>

We chat with Andrew, Product Lead on the Biden campaign and former LinkedIn PM

Product Thinking: 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 src="https://inputlogic-develop.s3.amazonaws.com/input-logic-website/12039596_10205221788726492_6369753080506531492_n_(2).jpg.jpeg"></p><h2><strong style="background-color: transparent;">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?</strong></h2><p>I grew up always wanting to work in the IT industry&nbsp;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&nbsp;in my blog&nbsp;— 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&nbsp;<a href="docs.microsoft.com" target="_blank">docs.microsoft.com</a>&nbsp;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><strong style="background-color: transparent;">What are the unique challenges you're facing in your role right now?</strong></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, "<em style="background-color: transparent;">we're not working remotely. We are working remotely during a global pandemic.</em>" This is not your typical 'work from home' environment.</p><h2><strong style="background-color: transparent;">What is your unique ability that has allowed you to succeed in product roles?</strong></h2><p>Skill stacking. Something that I've learned from my good friend and mentor <a href="https://twitter.com/danielfe" target="_blank">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&nbsp;<span style="background-color: transparent;">today</span>. 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><strong style="background-color: transparent;">What's one thing you've worked on that you're really proud of?</strong></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&nbsp;<a href="https://docs.microsoft.com/en-us/" target="_blank">docs.microsoft.com</a>&nbsp;— 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&nbsp;<a href="https://docs.microsoft.com/en-us/python/api/" target="_blank">Python API Browser</a>&nbsp;or the&nbsp;<a href="https://docs.microsoft.com/en-us/dotnet/api/" target="_blank">.NET API Browser</a>. We've built an entirely new experience to aggregate all code samples that Microsoft ships in the&nbsp;<a href="https://docs.microsoft.com/en-us/samples/browse/" target="_blank">samples browser</a>. And of course I can't neglect mentioning <a href="https://docs.microsoft.com/en-us/learn/" target="_blank">Microsoft Learn</a>&nbsp;— 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><strong style="background-color: transparent;">How do you foster collaboration within your team? Any tools or processes that are working really well this year?</strong></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" target="_blank">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 "<em style="background-color: transparent;">time to sync</em>" or "<em style="background-color: transparent;">discuss during the planning meeting.</em>" 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><strong style="background-color: transparent;">How do you manage prioritization and roadmapping?</strong></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 style="background-color: transparent;">Quantitative data</strong>. Do we have any numbers that point us towards the importance of certain things?</li><li><strong style="background-color: transparent;">Qualitative data</strong>. Do we have any verbal/written feedback that&nbsp;points us towards the importance of certain things?</li><li><strong style="background-color: transparent;">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 style="background-color: transparent;">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 "<em style="background-color: transparent;">Why</em>" and "<em style="background-color: transparent;">What.</em>" Everything else comes from these insights.</p><h2><strong style="background-color: transparent;">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?</strong></h2><p>These are not mutually exclusive. You can't rely&nbsp;<em style="background-color: transparent;">just&nbsp;</em>on data or&nbsp;<em style="background-color: transparent;">just&nbsp;</em>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&nbsp;<em style="background-color: transparent;">why</em>&nbsp;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&nbsp;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 "<em style="background-color: transparent;">this is likely the blocker</em>." 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><p>As a PM grows in the role, their intuition becomes better — you don't need an experiment to tell you that making a button of a different color on the screen where everything else is relatively monotone is going to increase engagement. You also don't need experiments to know how to make things more usable for customers (e.g. making labels clearer, making the site faster) — a product sense there is paramount. I would never consider my intuition alone, though, as the sole determining factor for the direction of a product or feature&nbsp;<em style="background-color: transparent;">unless</em>&nbsp;there is absolutely no data available, which is unlikely. You can always get data if you get out of the bubble and listen to customers.</p><h2><strong style="background-color: transparent;">What's your favorite app right now? Why?</strong></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&nbsp;<a href="https://overcast.fm/" target="_blank">Overcast</a> by Marco Arment. It's a delightful podcast manager.</p><h2><strong style="background-color: transparent;">What's the last book or podcast interview that totally wowed you?&nbsp;</strong></h2><p>Probably too many to name — I consider myself to be&nbsp;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&nbsp;<a href="https://www.chapters.indigo.ca/en-ca/books/founders-at-work-stories-of/9781430210788-item.html" target="_blank">Founders at Work</a>&nbsp;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&nbsp;<a href="https://gimletmedia.com/shows/startup" target="_blank">StartUp</a>&nbsp;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>

The Input Logic team chats with Microsoft Principle Cloud Advocate Den Delimarsky about product management, strategy and prioritization.

Product Thinking: an interview with Microsoft's Den Delimarsky

Product Thinking: 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.&nbsp;</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/" target="_blank">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" target="_blank">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 <em>more</em> 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 <em>not</em> to build at this point is even more important than deciding what <em>to</em> build.</p><p>Another way to think about this: if you knew you only had <em>x</em> 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://inputlogic-develop.s3.amazonaws.com/input-logic-website/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/" target="_blank">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><strong>﻿</strong><img src="https://inputlogic-develop.s3.amazonaws.com/input-logic-website/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://inputlogic-develop.s3.amazonaws.com/input-logic-website/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>

How to build and launch a tech startup without a technical cofounder… and without learning to code. This guide walks you through step by step.

How to launch a startup without a technical cofounder

The zero-to-hero guide to building a tech startup when you’re not a developer

<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&nbsp;<a href="https://developer.apple.com/support/app-store/" target="_blank">widespread adoption of iOS 13</a>, SwiftUI deserves a serious look when making your next app.</p><h3>Better UI structure, I do declare!</h3><p><img src="https://inputlogic-develop.s3.amazonaws.com/input-logic-website/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&nbsp;<strong>what</strong>&nbsp;to do, and imperative as&nbsp;<strong>how</strong>&nbsp;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&nbsp;every single time&nbsp;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://inputlogic-develop.s3.amazonaws.com/input-logic-website/swift2.jpeg"></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><img src="https://inputlogic-develop.s3.amazonaws.com/input-logic-website/swift3.jpeg"></p><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&nbsp;<a href="https://developer.apple.com/videos/play/wwdc2020/10041/" target="_blank">here</a>.</p><p><strong>Looking for help designing and building your product?</strong>&nbsp;Get in touch below.</p>

SwiftUI is the future of development for Apple platforms, including iOS, tvOS and macOS. We outline key features, and reasons why it's time to start using it.

5 Reasons Why iOS Developers Should Switch to SwiftUI

Why you should build iOS apps with SwiftUI

<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&nbsp;operating systems, iOS and Android, there are an array of choices on&nbsp;how&nbsp;to build upon them. This is a common question from&nbsp;our clients&nbsp;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?</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>

Choosing the right platform to develop your mobile app is key. Here's how to choose between native, React Native, Progressive Web Apps and NoCode.

How to choose a platform for your mobile app

Choosing between native, React Native, Progressive Web Apps and NoCode

<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 <a href="https://www.inputlogic.ca/" target="_blank">Input Logic</a>. 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><h3>Why React Native?</h3><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://inputlogic-develop.s3.amazonaws.com/input-logic-website/react2.png"></p><h3>Before You Start</h3><h4>Is React Native right for your project?</h4><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><h4>React Native != Web</h4><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><h4>Understanding Native Development</h4><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><h4>Advice From My Experience</h4><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://inputlogic-develop.s3.amazonaws.com/input-logic-website/react3.png"></p><h4>Use the APIs, Luke</h4><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><h4>Upgrading React Native</h4><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&nbsp;rn-diff&nbsp;so we know what to expect, while using&nbsp;npm-check-updates&nbsp;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><h4>Versioning and Data Persistence</h4><p>If you’re using something to persist your application state like&nbsp;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><h4>Navigation</h4><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><p><img src="https://inputlogic-develop.s3.amazonaws.com/input-logic-website/react1.png"></p><h4>Libraries for React Native</h4><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" target="_blank">react-native-firebase</a>&nbsp;— 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" target="_blank">tipsi-stripe</a>&nbsp;— 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" target="_blank">date-fns</a>&nbsp;— 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" target="_blank">react-native-svg</a>&nbsp;— A great library for using SVGs in your app, and was especially helpful when implementing custom map markers with&nbsp;<a href="https://github.com/react-native-community/react-native-maps" target="_blank">react-native-maps</a>.</p><h4>Other Considerations</h4><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><h3>Final Thoughts</h3><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>

React Native is a great mobile app platform for startups and enterprise businesses alike. Here's how we use React Native for cross-platform app development.

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

How we build mobile apps with React Native at Input Logic

<p><a href="https://www.inputlogic.ca/work" target="_blank">We build a lot with Django</a>. 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" target="_blank">You can find the GitHub repo here</a>.</p><h3>Local dev</h3><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/" target="_blank">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><h3>File structure</h3><h4>Apps</h4><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><pre class="ql-syntax" spellcheck="false">apps/
&nbsp;someapp/
&nbsp;&nbsp;views.py
&nbsp;&nbsp;tests.py
&nbsp;&nbsp;...
libs/
&nbsp;filters.py
&nbsp;...
project/
&nbsp;settings/
&nbsp;&nbsp;common.py
&nbsp;&nbsp;local.py
&nbsp;&nbsp;production.py
</pre><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="https://github.com/joke2k/faker" target="_blank">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><pre class="ql-syntax" spellcheck="false">git push heroku master
</pre><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>Thats what we’ve got so far and its been working great. We plan to add a few additional things. Mostly related to front-end.</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>

Django is one of our favorite frameworks. Here's how we prep for local dev, production configs, and test integrations with our Django 'starter project.'

Starting your Django project on the right foot

How we build with one of our favorite frameworks

Blog

Interested in working together?

Work

About

Contact

Subscribe