Welcome to the Tech for Non-Techies podcast

When an app has too many features and pop ups, most users get confused and frustrated. This is feature creep: when the product’s core functionality becomes hidden in too many options and things to do.

Feature creep happens when a team is determined to stay productive, but loses sight of its strategy. Sometimes stopping is better for the product than doing more.

Learning notes from this episode:

• Feature creep is problematic for two main reasons: it confuses users and it costs money. This is because product teams have to be paid to design and code, and you also have to pay cloud costs to store your pointless features.
• Feature creep happens when there is a pressure to produce, which is contrary to the ability to focus. It can be easier to present new features as productivity to investors and corporate bosses, rather than saying that the product team took time to review results and reflect.
• To prevent feature creep, go back to the fundamental product development questions...

Developers don't work in the same ways as non-technical professionals. If you don't know how to work with developers, you can waste thousands of dollars and get very frustrated, as you'll see from the story Sophia shares on this week's episode.

Learning notes from this episode:

• A feature cannot be released when it is not ready. It is either ready to release, or it is not. There is no half way line. A feature can't be half ready, just like you can't be half pregnant. 
• Developers usually work in two-week cycles, when they are focussed on a specific set of tasks. For example, in a two week period, developers may be working on a specific feature for an app. Then they release it, and start on another feature.
• Since what developers do affects the rest of what the product team does, this lesson is relevant if you want to work with other people in the product team, like designers, community managers and data scientists.
• Corporate accelerators for technology start-ups, which...

The terms coding and programming are ubiquitous, yet many non-technical professionals do not know what they mean in practice. Why are there different coding languages? What do developers actually do?

This is what you'll learn in this episode.

Learning notes:

• Data is information that you can use to do something with. For example, your shopping list is information that you use to remember what food to buy when you go to the supermarket.
• Technology is what you use to create, store or communicate that data. In our shopping list example, it could be pen and paper, or the notes app on your phone. 
• In order to make software, you have to tell a computer what to do. You do this via a programming language. All digital technologies are created by using specific coding languages to turn data into useful outcomes.
• Python Java, C++ and Ruby are the most popular languages  today. But, there are 256 coding languages in use today.
• Binary code, also known as ...

Agile is now a ubiquitous management term, but few people understand what it means in practice.

For some products, agile is THE BEST system, for others, it is THE WORST.

Listen to this week’s episode to find out what it is, how it works in practice, when to use it and when to avoid it.

You’ll hear how WhatsApp used this methodology to release its first product, and learn how to use it yourself.

Learning notes from this episode:

• There are two methodologies to make things: waterfall and agile.
• Waterfall came from manufacturing and construction and emphasises planning in order to release a perfect product. For example, if you’re building a house, you need to plan ahead and only let people move in to live in it when it is complete.
• Agile methodology is an iterative process, used by software developers. Simple changes get released frequently, in response to user needs or technological changes. The product is by definition never complete, because it is always changing.
...

Every app and site is made up of lots of different tech tools and languages. Like a house, one part is built on top of another and they need each other to function. If one part of the structure breaks, the rest can fall down too. 

These are called dependencies. To keep a product working, all the dependencies need to work together. This is part of the invisible work that software engineers do.

Learning notes from this episode:

• A tech stack describes all the tools and programming languages used to build an app or a site. Some of those tools are custom made, some are rented as licences and others plug you into a bigger ecosystem.
• Examples of bigger eco-systems that many products depend on are the Apple App Store, Google Play and Amazon Web Services. If one of these ecosystems has a problem, the apps and sites they support will have issues too. An app on the Apple App Store depends on Apple, hence the term dependency.
• Product teams have to update...

“Come to developers with good research and understand your customer. If you don’t understand your customer, how can you expect the developer to build features for that customer?” says developer Ariana Waller, founder of Wally Tech.

Ariana works with non-technical founders and helps them bring their visions to life. But, many founders want to hire developers too early or make the wrong hires.

Listen to this episode to avoid falling into that common trap.

Learning notes: 

• Learn about the users and the problem you are solving before you speak to developers.
• Use no code apps to build solutions before you hire a developer to test your product. This will help you save on development costs and help you test your product before committing to paying for custom code.
• Good developers will ask you questions about your users and your business model because they want to participate in projects that are likely to succeed. Even if you’re hiring outsourced product...

Every time you send a message on Whatsapp, it goes through the server. Every time you look back at your old Instagram photos, the server brings you your data.

Servers are a key component of almost all apps, and they work like the brains of the operation. Their main task is to enable communication and store data.

If you want to build tech products or invest in them, you need to know this key concept.

Learning notes from this episode:

• The front end is a computer that speaks to humans. The bit of an app or site you interact with is called a front end. If you can touch it, swipe it or speak to it, it is a front end. 

• The front end is like your sensory organs: eyes, ears and mouth.

• The back end (the server side) is the bit of the app that you cannot interact with yourself: it is a computer that only talks to computers.

• The server is the brain of your operation: it enables communication and stores data. 

Listen here on Apple Podcasts...

If code gets written, that usually means that there's technical debt. If it isn't dealt with regularly, the product doesn't work properly, engineers leave and you'll have a rebellion on your hands.

In this episode, you'll learn from Alexandre Omeyer, founder of Stepsize, the core concepts that non-technies need to know about technical debt.

This is must know concept for founders, product managers and smart investors.

Learning notes from this episode:

• Technical debt is the mess that gets left over from writing code and should be regularly cleaned up in order for the engineering team to work properly.
• Alexandre suggests thinking of the tech development process like a restaurant kitchen. Having spillage and potato peels dropping on the floor is a normal part of the cooking process. But if you do not have a regimen to clean up, you will end up with a filthy kitchen that will affect your food (i.e. your product) and your customers will get sick.
• Non-techies need to know that technical...