1.
Agile Product
Development
Using agile and lean startup principles to create
software products more efficiently

2.
About Me
CTO of Leflair
Worked in software consulting for a
little over a decade.
Delivered products, websites, and apps
for some of the biggest brands on earth.
Consulting with multiple small
businesses and startups.

3.
Why this talk?
● Companies waste large
amounts of time/money on
useless work
● Frustrated teams
● Angry investors
● FAILED PRODUCTS

4.
What I want you
to get out of it
● Understand connection
between product management
and agile software development
● Understand key principles of
efficient product ideation,
validation, and delivery
● Clear next steps/sources for
learning

5.
Product Development
vs
Software Development

6.
Agile Software Development
When you hear “agile software development”, what comes to mind?
What ideas have you heard?
If you do “agile development”, what do you expect to do?

7.
Agile Software Development
Agile does not mean “fast”
Agile does not mean “cheap”
Agile means “responds to change”

8.
Agile Software Development
Different frameworks:
● Scrum
● Kanban
● Extreme Programming (XP)
● Dynamic Systems Development Method

9.
Agile Software Development
Discuss you experiences
- Those in the workforce: have you done agile?
- Those in school: What have you learned about agile?

10.
Agile Performance Art
A lot of companies do “agile” by having standups,
sprints, and other rituals associated with agile
development while ignoring the key principles.
➔ Meetings without representation
Engineering chooses what to do without talking to
business leaders. Business chooses what to do
without discussing with engineering. Nobody
actually talking to the customer.
➔ Fundamental misunderstanding of the
point of agile.
Agile is about responding to feedback and change.
Many businesses just see agile as “fast”, without
understanding it.

11.
Product Development
When you hear “Product development” what comes to mind?
Question: What’s do you think is the difference between product development
and software development?
Question: What might be some goals in product development?

12.
Product Development
Modern Frameworks include:
LEAN product development
Design Thinking
Front End Innovation
4 Ps (not the pizza chain)
Product Led Growth

13.
Design Thinking
Empathise Define Ideate Prototype Test

14.
The 4 Ps
● Place (where should we sell)
● Product(what are we selling)
● Promotion(how are we marketing it)
● Price(what is the best price)

15.
When does
Product Development
become
Software Development
And vice versa?
(discuss)

16.
Software Product Development
New software product development is the process of generating, iterating,
and testing the creation of new software products.
Product development is about WHAT is being delivered and to WHOM, and
WHY
Software development is about HOW that product is constructed and HOW
the value is delivered, and WHEN things can be completed.

17.
Key Principles
● Understanding the customer, their frustrations, their context.
● All team members should understand the customer problem.
● Divide between “business” and “technology” is role, not information (ideally).
● Improvements, refinements, and simplifications are invited at all times from all team members.
● What is delivered, how it is delivered, and to whom it is delivered are all under constant
refinement and improvement.
● Everything is an experiment.

18.
Agile Product Development
Uniting agile software development methods to product development
frameworks.
● Combines business needs and development tasks.
● Ensures that context is understood across all teams.
● Invites creativity and pushback.
● Maximizes value from diversity

19.
Agile Product Development
● Unite the what, the who, the why, and the how
● Scale effort organically
● Find traction cheaply
● Understand future scaling and support needs early.

20.
If it’s cheaper, faster, and effective…
Why Doesn’t Everyone Do It?
(discuss)

21.
Technology changes fast.
People and
Organizations do not.

22.
Example 1
A high-ranking business executive declares
that the business needs “a new website” and
demands the engineering team build
something “cooler and more modern”:
➔ What is the goal?
The engineering team does not really
know the problem they are solving,
other than to make the executive
happy. Does the executive even know
what they are solving?
➔ How do you know it worked?
There is no way to study success. Even
if there is a “cooler and more modern”
website, what does that achieve?

23.
Example 2
A business examines their analytics and sees
that most customers are coming from mobile
devices. They decide to launch a new mobile
app.
Is this good or bad? Why?

24.
Example 2
A business examines their analytics and sees
that most customers are coming from mobile
devices. They decide to launch a new mobile
app.
➔ What does the app provide that
the website does not?
Are customers unhappy with the
website? Most importantly - why?
➔ How do you know it worked?
While it’s possible to know if you
launched a mobile app, what metrics
are we trying to improve? What is our
experiment?

25.
Example 3
A shoe company notices that their sizing page
has a large number of hits. They wonder if
this means their sizing is confusing. Or
perhaps customers are looking for custom
sizes? What else could it mean?
How would you approach this?
What other data could you
collect?

26.
The causes of product
and project failure are
usually a combination of
People, Process, and
Communication

27.
Products as problem solving
Simple concepts:
Continual Context
Clear Criteria
Ongoing Conversation
Simple processes:
Minimal prototypes
Feedback and Iteration
Avoid features

28.
Prototypes

29.
Prototypes
Avoid writing code.
Avoid making designs.
“What’s the cheapest/fastest way to test?”

30.
Prototypes
Tools:
● Balsamiq/Mockflow
● Marvel app
● InVision
● Zeplin

31.
Cheap Experiments
Everything is an experiment.
It’s not about being right or wrong, it’s about feedback, data, and refinement.
Lots of organizations get this wrong.
Bad approach - building based on who likes something and who told you to do
something when neither of those people are the actual customer.

32.
Cheap Experiments
Get Real Data
Opinions that are not from the customer are not data.
Great ideas that you are “totally sure will work” are not data.
Real data comes from customers/potential users

33.
Exercise:
Discuss issues you have in a group.
Do NOT come up with a product.
Find a problem that needs solving.

34.
GOOD
“Tell me about your frustrations in X...”
“What is the impact on your work?”
“What are you trying to achieve?”
“Would you pre-pay for X today?”
BAD
“Do you want a mobile app?”
“We’re building X, this helps your
problem right?”
“You would totally buy this, right?”

35.
The Most Important Thing
Understanding the customer, their problem,
and their context.
The better you understand their wholistic
experience, the better you can solve their
problem.

36.
When to invest in code?
When the potential customer is enthusiastic.
When you have real data showing a market.
When you know your USP vs competitors.
When someone will pay in advance.

37.
Market Timing, Marketing, and Sales
Engineers care about engineering, product managers care about
products, etc.
A lot of success is timing, marketing/positioning, and sales skill.
Example: Apple Newton vs Apple iPhone.

38.
The best product
Doesn’t always win.
Strategic alliances
Influencers / pay-to-play media coverage
Market access
Government interference

39.
The best product
Doesn’t always win.
BUT IT SURE HELPS

40.
Takeaways & Lessons

41.
Key Ideas
1. Understand your customer’s world, their pains.
2. Work smart - minimize efforts.
3. Everything is an experiment.
4. Maximize learning vs costs.
5. Everyone can have insight.

42.
Things to research
● LEAN startup principles
● Agile Software Development approaches
● Design Thinking
● Blue Ocean vs Red Ocean markets
● Growth Hacking
● Porter’s 5 forces
All of these are connected. All of them are about thinking about the
customer/business experience first, to create new things.

43.
Engineering

44.
Speedy Development
The moment you find traction, you want lots of
automation.
● The less time you spend fighting fires, the more time
you have to write new code.
● Automated tests let you refactor safely.
● Automated deployment lets you deploy safely.

45.
Refactor code into small units.
Pull behavior into pure functions as much as possible.
● Pure functions are easy to compose and easy to test.
● Functional programming is great, but you don’t have to
go that far.
● The real key is quality encapsulation, no matter how
it’s achieved - avoid lots of inheritance, favor
composition.

46.
Refactor into services.
If functions are a natural unit of code, services are a
natural unit of architecture.
● Clear responsibility
● Clear API
● Testable, injectable, mockable

47.
Tools
It’s good to become familiar with tools that help you build
and test services and microservices
● Docker + Docker compose
● Hoverfly
● Selenium/Cypress/Puppeteer

48.
Avoid Choices
Making a choice and moving on is a better choice than
over-deliberation. Something is better than nothing.
● Pick and use a code style. Automate formatting.
● Pick a minimum code coverage level, enforce it.
● Create a standard story/ticket template. Always use it
and reject anything that doesn’t.

49.
End. Questions?