Connect with us

Startups

3 Important Lessons I Learned From Working in a Digital Startup

Published

on

digital startup

It’s been just over 2 years.  I must admit it definitely feels longer than that. So much has happened within that timeframe, in an environment where a day feels like a month. I mean, what could possibly make someone want to leave a safe, stable job building teams and solutions within the Enterprise to start from scratch?  Glad you asked.

The glory certainly exists in start-up land and the feeling of contribution is immense when things are going well. The highs are superb. But with the highs come the ‘waking up at 3am in a cold sweat’, the ‘constant obsession to make things better’ and the ‘all rational thought would indicate this should work well, but analytics is clearly telling a different story’ moments, which can test even the strongest of characters.

As CTO of an automotive start-up, Autoguru, I thought I’d share some key learnings at which the experienced amongst us can have a laugh and say “I’ve been there before!” And to those (less?) fortunate newcomers to the startup world, hopefully you’ll learn a little something from these words of wisdom.

Here are 3 things I learned from working in a Digital Startup:

Lesson 1: Don’t build what’s already been built

Need a way to track customers effectively and ensure the right offers are sent to them at the right time? Don’t build it.  There are countless CRM (Customer Relationship Management) systems out there you can integrate with.

Does your solution need to scale massively, have millisecond response times and be fault tolerant down to a micro-service level with monitoring to the nth degree?  Again, there are a myriad of options available in AWS, Azure and Google Cloud that will provide these features without your development teams ever having to break into a sweat.

Do you have an existing product that’s inflexible and refuses to play nicely with other systems?  Ok, so this is where you should consider other options, and if there’s no ‘off the shelf’ product available it’s time to consider an API platform or custom build.  

This was precisely the scenario with our call centre application at AutoGuru, and by replacing it with the Twilio platform we were able to tightly integrate all our communication touch points into back end systems and create a framework where we control the roadmap for improved customer interaction.

The key point is we’ve never been in such a fortunate position where AI, Chatbots, advanced analytics, CRM, CMS, (the list goes on), are all available and at our fingertips for a fraction of the cost compared to just a few years ago.

Development teams should be intent on building your product.  That thing that differentiates you from your competitors. Your secret sauce. Your delighter. That’s where your focus should be.

You can save a lot of time and effort in finding the right products, so if you want to check out what other successful tech companies are using, check out StackShare.

“Don’t reinvent the wheel, just realign it.” – Anthony J. D’Angelo

Lesson 2: You don’t have 6 months, see what you can build in 2

Your product is new, unproven and there are a thousand ideas floating around to improve it and make it better, faster, more user friendly. When it comes to larger ideas that perhaps take your company in a new direction or into a completely new marketplace or partnership, it can be easy to sink a lot of resources and time into these kinds of initiatives.

Time is something you don’t have.  And if you do, you’re amongst a tiny percentage of very lucky startups! Smart people possess an uncanny ability to look into the future and foresee every variation and edge case for what may or may not happen when a feature or product is built.

The difficult part is rationalising the probability of these various outcomes eventuating, so you’re essentially not wasting energy (in many cases) on improbable events.

If you give a product team 6 months to build a product they will take 6 months as they fill time with small probability edge cases – the ‘what if’s’ for want of a better term.  

Taking the same product and seeing what can be built in 2 months will focus everyone’s energy on the core of what’s being built and how it can best serve a customer. The edge cases will most likely come, but at least you’ll already have a product in market!

Lesson 3: Shortcuts will come back to bite you…eventually

It may seem contradictory to Lesson 2, but there are some shortcuts you will most certainly come to regret in the long run.  Here are a few standouts I think it’s only right to mention:

  • Failing to have effective analytics
    Analytics is sometimes the poor cousin of a feature but if you can’t measure you can’t learn.
  • Automation is key
    Code deployments?  – Automate
    Server environments? – Automate
    Unit/Integration test? –  Automate
    Ok, you get the picture.  It may take longer initially but you’ll save time in the future by making these investments.
  • Failing to Prioritise
    All team members are super busy and working hard.  Congratulations!  However, by not investing the time in continual, harsh, cold blooded prioritisation using methods such as MoSCoW or ICE it could all be in vain.  A handy comparison of prioritisation methods is available here.

Fortunately, I learnt some of these lessons prior to working at AutoGuru, however, in a startup environment it’s wise to keep referring back to base principles, as every day counts.

What are your experiences in Digital Startups? Please leave your thoughts below!

Image courtesy of Twenty20.com

Barry Pryce is a technology leader with experience in enabling Digital Transformation across several industry sectors including banking, telecommunications and media. A specialist in Agile, cloud computing and customer centric application delivery, Barry is currently focused on bringing best of breed digital experiences to the Automotive industry, as CTO at AutoGuru. In previous roles, Barry has helped with the digital transformation of RACQ and achieved Australian digital media firsts including MasterChef and Formula 1 Live Streaming. Barry loves surfing (ex Interceltic games – Scottish Surf Squad), fishing, and obsessing over his veggie patch. But that’s another story.

Advertisement
4 Comments

4 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

Startups

Move Fast without Breaking People: Product Safety Lessons for Ambitious Startups

Published

on

Image Credit: Addicted2success

Fast growth can hide product risks until customers get hurt, especially when safety comes late in development. A software bug can be patched, but a chair, charger, or smart device can cause a burn, fall, cut, or crash.

For founders moving from a prototype to mass sales, the cases handled by Michael Kelly Injury Lawyers in Boston show why launch goals should not push testing, warnings, and foreseeable risks aside. A product claim can involve the design, how a unit was made, user instructions, or several firms in the supply chain.

Why Minimum Viable Should Never Mean Minimally Safe

A minimum viable product should test whether people want an idea, not how much danger they will accept. Teams can delay colors or premium finishes, but not guards, safe heat limits, sound wiring, or clear instructions.

Set Safety Rules Before the Build

The product brief should define who will use the item, where, and what could happen during setup, cleaning, storage, wear, or mistakes. It should also consider what a child, guest, tired worker, or first-time buyer might do.

Shared rules help teams move faster. Designers know which guards must remain. Engineers know which parts cannot fail. Suppliers know what cannot change without review.

Test How People Really Use It

A neat demo is not the real world. Users place products on wet counters, soft rugs, or rough ground. They skip a guide, use the wrong cable, or handle an item in unexpected ways.

Testing should cover misuse without predicting every extreme act. When a risk can be reduced through a guard, lock, stop switch, or clear signal, that design change is often greater than a warning alone.

How Design and Manufacturing Risks Differ

Some risks are built into the design. Others arise when production fails to match the approved plan. Teams need to identify the source before choosing a correction.

Design Problems Start with the Plan

A design problem can affect every unit. A base may tip, a blade may sit too close to a hand, a control may activate too easily, or a battery space may trap heat.

Final inspection cannot repair a flawed plan. The team may need a new shape, shield, limit, material, or control, followed by testing before more units ship.

Manufacturing Problems Break the Plan

A manufacturing problem occurs when a unit or batch does not match the approved design. A fastener may be missing, a weld may be weak, a wire may be damaged, or the wrong component may enter production.

Good records help define the scope. The team should know who made each part, which batch used it, what checks occurred, and where units went. Fast trace work can keep one fault from becoming a wider crisis.

When Customer Feedback Signals More Than Dissatisfaction

Support teams hear about delays, difficult setups, strange sounds, and refunds. Most reports are routine. Yet heat, smoke, sparks, breakage, sharp edges, sudden movement, falls, or failed guards require review.

Treat Complaints as Safety Data

One report may lack key facts, but similar reports can reveal a pattern. Staff should record the model, batch, date, use, photographs, and outcome, then alert someone who can pause sales or order testing.

Teams should not blame unusual use before asking whether another reasonable buyer could make the same choice. A support ticket can be the first sign of a hazard that lab testing missed.

Preserve the Product and the Record

After an injury, the product can help explain what failed. A repair, disposal, or undocumented test can remove evidence. The same applies to old labels, manuals, test files, customer messages, and design notes.

Startups should keep relevant items safely, record who examines them, and preserve earlier versions of instructions and warnings. This history can show what changed and why.

Why Warnings Must Reflect Real Use

A warning works only when a user notices it at the right time. Dense text at the back of a manual may not help during setup. The message should name the hazard, explain the harm, and state what reduces the risk.

Placement matters too. A charging risk belongs near the port. A weight limit belongs where weight is added. Even so, warnings should not replace a safer design when the hazard can reasonably be removed.

How Founders Can Preserve Speed without Cutting Safeguards

A delayed launch, redesign, or recall can feel like defeat. In practice, early action can prevent harm, protect trust, and give the team better facts for the next version. The strongest startups move quickly because their systems protect people.

When a product injures someone, legal guidance can help preserve the item, collect design and manufacturing records, identify responsible companies, and examine whether a defect or unsafe choice caused the harm.

Continue Reading

Startups

How to Choose the Right Tools as Your Startup Scales

Choosing the wrong tools can slow your startup down. Here’s how to pick what actually fits your stage of growth.

Published

on

operational systems for startups

There’s a point in every growing business where things stop feeling simple. Not broken, just heavier. (more…)

Continue Reading

Startups

The New Startup Toolkit (2026): What You Actually Need to Get Noticed

Most startups don’t fail because of bad ideas, they fail because no one notices them. Here’s what actually works in marketing today.

Published

on

how to get noticed as a startup

Most startups don’t fail because of a bad idea. They fail because no one notices them. (more…)

Continue Reading

Startups

This is the Silent Killer of Startup Growth in 2026

Bad UX design quietly drives users away, draining startup growth before founders even realise what’s happening.

Published

on

How UX design improves product growth

Bad UX design doesn’t announce itself. There’s no alarm, no flashing warning light – it just quietly bleeds your startup dry, one frustrated user at a time. (more…)

Continue Reading

Trending