Uniting product development, business strategy, and agile software practices.
Covers thinking about product development wholistically from a customer-first perspective. Suggests good principles for established companies and boostrappers.
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
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?
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
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)
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)
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
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
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.
39.
40.
41. The best product
Doesnât always win.
Strategic alliances
Influencers / pay-to-play media coverage
Market access
Government interference
44. 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.
45. 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.
47. 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.
48. 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.
49. 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
50. 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
51. 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.