This presentation is your guide on how to Best Develop a Product from scratch. Learn the best methodology on how to succeed in developing a product.

1. www.productschool.com
How to Best Develop a Product by
PlateRate Founder

2. FREE INVITE
Join 30,000+ Product Managers on

3. COURSES
Product Management
Learn the skills you need to land a product manager job

4. COURSES
Coding for Managers
Build a website and gain the technical knowledge to lead software engineers

5. COURSES
Data Analytics for Managers
Learn the skills to understand web analytics, SQL and machine learning concepts

6. COURSES
Digital Marketing for Managers
Learn how to acquire more users and convert them into clients

7. Garret Lang
TONIGHT’S SPEAKER

8. What are the goals?
What are the goals of software development?
1. Maximize value - Maximize the chance of building something valuable
2. Minimize waste - Minimize wasted time for all parties (developers, product, sales, customers)
3. Fast to market - Bring capabilities to market more quickly
4. Adopt to customer needs - Be able to adopt quickly to customer needs
5. Validate work before building - This helps you minimize waste and maximize value

9. What are the alternatives? 1) Waterfall
Waterfall was the predominate method of building software prior to around 2010 or so, when agile really
took hold. Here’s how waterfall works:
1) Scope out your project (very high level scope)
2) Gather detailed requirements (create 200-400 page requirements docs with specs and diagrams) -
could take 6 months - 2 years
3) Build the product - Could take 1 year - 3 years
4) Test the product and fix bugs - Could take 3-6 months
5) Launch the product & hope it gets adopted
This is a brand new UI/UX/product, completely different from what users used to use… Adoption rates
were historically very low, and many $100M+ projects were cancelled due to lack of user adoption

10. What are the alternatives? 2) Agile
Pure agile breaks work into smaller chunks of work, called “Sprints” which allows many small releases of
functional software
1) Scope out your project (very high level scope)
2) Break your story out into epics and user stories, in the agile user story format (few weeks)
3) Pick a bunch of user stories for your first sprint
4) Build the software, show it to users, get feedback, and make modifications to the software as user
feedback comes in (mid-sprint) (2 weeks sprints is the norm)
5) Testing is done during the sprint, so when the sprint is done, the software should be ready to release
6) Release new capabilities every 2 weeks
Problem? You end up with lots of re-work mid sprint because the definition of work that needs to be done
from a user story alone is not clear enough to remove ambiguity… so developers end up spending a lot of
time on rework.

11. What are the alternatives? 3) Garrett’s modified Agile
Garrett’s “modified” agile creates a clear compelling problem/solution/design spec for each capability, then
queues up a backlog of well-defined and customer-validated work to the development team.
1) Identify the problems you want to solve. Force rank them in terms of impact/effort so the high
impact low effort problems are prioritized first
2) Product starts from the highest priority problems, define business/process solutions, create mockups
showing a vision of the solution that is clear
3) Share the problem/solution/vision with all stakeholders (Product team, sales, client development,
even current or prospective customers). Get feedback, incorporate feedback. Iterate until people
are excited.
4) Put the exciting vision for problem/solution/vision in the development backlog, get an effort estimate
5) Prioritize the development backlog by impact/effort
6) Developers build the software doing development testing
7) QA then Product test the software to be sure it meets needs (regression tests are ideal too)
8) Release exciting new capabilities to the client every 2 weeks

12. Comparison - Why use “Modified” Agile
Waterfall Pure Agile “Modified” Agile
Maximize value No No Yes
Minimize waste No No Yes
Fast to market No Yes Yes
Adopt to customer
needs
No Yes Yes
Validate work before
building
Yes No Yes

13. User story lifecycle
Problem - what business problem are you solving (& business requirements)
Solution - What’s your process/business solution to the problem (not technical solution) (Process
requirements)
Designs - let UX/designers/product mock up the solution in detail
Effort estimate / Tech Design - Effort to complete & high level design (Technical requirements)
Backlog prioritization - Prioritize on impact/effort
Development - Build it
QA/Load testing - Test it
Release it - Release & if needed train the customer how to use it

14. Lessons Learned from CMM
CMM - Capability Maturity Model - Was invented at Carnegie Mellon and was an innovative way to
capture requirements for software development. I use it in my modified agile approach. Let’s define each
of these terms.
Business Requirements (Part of Problem) - Business goals that need to be achieved, the WHAT must
be done, without regard to HOW it gets done
Process requirements (Part of Solution) - The methodology of how something gets done, from a process
and functionality perspective. Sometimes called functional requirements. Every process requirement
should be accomplishing a business requirement
Technical Requirements (part of tech design) - Technical assumptions / things the technology team
assumes must always be true in order to achieve the process requirements. Every technical requirement
should be mandated by a process or business requirement.

15. Problem
It’s important - This is the most important part of the lifecycle. If you haven’t
clearly defined a problem important to your customers, all the rest of the lifecycle
is a waste of time.
Be clear and precise - Be sure your problem is clearly and precisely stated, but
written in terms your customer can identify with easily.
Stay focused - Clearly articulating your problem will help you be sure you’re
solving it thoroughly with your solution. If your problem is stated ambiguously, you
may spend a lot of time building solutions that don’t address your problem well.

16. Solution
Your solution should clearly describe how you’ve solved the business problem. Your customers should be
excited when they hear it and see your designs.
How solutions should be described is on the following page
Your solution should describe every object, field, value, and capability related to how the problem will be
solved. If you haven’t gotten to this level of detail yet, get there and vet it all with your stakeholders.
Use tables, diagrams, flow charts, text descriptions, designs (coming next) to lay out the solution visually
so it is easily understood and vetted. Its ideal to create click-through mockups to simulate the user
experience to stakeholders.
$ Value - I strongly encourage trying to tie a $ revenue value to each solution. You can do this with
salespeople but ideally ask customers what they’d pay for the solution/design you’re proposing.

17. Solution/Design format
Component of User Story Description
Solution/User Story
What's the business and process solution. Write the business solution in user story format. What capabilities must the
user be able to do in this user story (name the screen they should be able to do it on, and the capability they need)
Design
All visuals required to describe the solutions so its crystal clear. Mockups of the screen, text of error messages,
formatted examples of emails, etc.
Requirements
What must always be true at all times or under certain conditions on this screen. If there are conditions, name the
conditions as well as what must be true.
Acceptance Criteria / Definition of
done
What tests must pass in order for this story to be considered complete. Phrase them like this: If I do x, then I expect y
to happen.
Analytics requirements
Given the new capability we added, is there something new we want to track in web analytics tools to track usage of
this capability?
Data required
What data is required to make this capability work? Eg we need same day interest rate data to calculate interest rate
hedge rates that are floating (or even to do floating rate calculations for our securitization products). This will trigger
the conversation about the feasability of getting any data we need to make this capability, which will drive
prioritization. We will populate with "N/A" whenever this is not applicable.
Marketing Notes
Notes that you want to consider for when you will market this capability to current and prospective customers. How will
you position this feature to them?

18. Design
Fidelity - If design elements are important, you should make it high fidelity. If the
design of your system is largely determined and you have a clear style sheet for
design, low fidelity mockups should be fine. If these are some of your first
mockups, or you’re redesigning your site, you should use high fidelity mockups to
design elements can be considered.
Click-throughs - I strongly encourage connecting mockups to create click-
through user experiences that simulate how the software will work when its
complete. They don’t need to be comprehensive, but they should allow a user to
walk through the main user stories / workflows similar to the way it will work when
the capability is built. Balsamiq (low fidelity) and invision (high fidelity) are the two
most common tools for doing this.

19. Vet & iterate on problem/solution/design
Now that you have a problem/solution/design vetted, and you know the problem is
one that’s important to your customers… vet it!
Share first with client development, then sales, then customers, then prospective
customers. Each time you share get feedback and improve the
problem/solution/design so its better for the next audience.
Once you’ve vetted and been responsive to feedback, you’re ready to queue this
up for the developers to give an effort estimate/design on.

20. Effort estimate / Tech Design
You now have a significant customer problem that you’ve solved on paper with your
solution/design, that you know customers will love when you deliver it. Time to start
executing.
Effort Estimate & Tech Design - Share this documentation with your developers. Ideally,
your developers will come back with an effort estimate, and ideally a technical design to
describe how they will technically deliver against the problem/solution/design you’ve laid out.
Review design - More technical product managers will be able to review this design to be
sure developers fully understood the scope of the problem/solution/design and that the
developers are solving it in a flexible, scalable way. You may need to iterate on the design a
few times to be sure the developers are building in a way that is flexible for future capabilities
you may want to add. Giving them insight into your roadmap and the backlog of high priority
problems will set them up for success proactively in this area.

21. Backlog prioritization
Hopefully you know have a $ value and an effort estimate. I encourage you to prioritize your
backlog based on impact and effort… High impact low effort things clearly come first, then
you need to decide between low impact low effort and high impact high effort… My advice is
to do a little of both in parallel so you show tangible deliverables in parallel to building
towards high impact medium-long term goals.
I suggest you should do your best to build up at least a 4-6 month backlog of well defined
work for any development team. If a development team has nothing to focus on, you’re
wasting resources… They should always have a healthy backlog they can look at… Also
giving them a 6 month view into what they’ll be building will help them architect more
intelligently not only for what they're building now, but what they’re going to have to build 6
months from now.

22. Development
Meet with developers no less than 2-3 times/week, ideally daily, so they can ask
questions about any ambiguities they run into.
Answer all questions they have as best you can. If you’re not sure, try to focus the
developers on something else in the sprint where there’s clarity until you can get a
definitive answer. You want to minimize the amount of rework developers need to
do.
Listen to developer’s feedback, they will often have good product ideas… Make
sure they know their opinion is valued and they’re a key part of the team. They’re
not just “do-ers” they’re team members too!

23. QA/ Load testing
Ideally, you have set of regression/sanity tests that run every time a new capability is integrated into the
code base, to be sure no currently working functionality breaks when new capabilities are released.
If you have this, you’re in a better situation than most and you should only need to test the new
capabilities thoroughly to be sure they meet the defined problem/solution/design specs as expected.
If you don’t have this, you also need to regression test to be sure no existing functionality broke.
If you have many users, you need to do scalability/load testing to be sure all capabilities that will be used
by many users simultaneously will work efficiently with realistic amounts of data and under high stress
situations (think cyber monday for retail sales level stresses…)

24. Release it
All new capabilities should be announced via release notes to customers, in a customer
friendly way with marketing-approved language.
If the capability is not intuitive, you should roll out user training in coordination with the
rollout, to teach customers how the new capabilities work.
You should make every effort to make releases as seamless as possible… Nothing that
used to work should break, but the customer should have new capabilities that make them
happier.
Monitor the usage of the new capabilities and ask for feedback on it. If there are small
tweaks you need to do to make it more user friendly, prioritize them in a soon upcoming
sprint.

25. On Working with Offshore
Development Teams
Garrett Lang

26. Agenda
Pros and Cons of offshore teams
Country-wide differences
How to make it work
- Teach the business, learn the technology
- Have a good development process
Ensure you have a balanced team
Clearly document what you want
Testing Strategy
Questions?

27. Pros:
● Low-cost
● Using offshore and onshore resources you can work around the clock
● Offshore resources can do support during nighttime hours during their day
Cons:
● Time-zones can result in less overlapping time during the day
○ I don’t recommend making offshore teams work daytime hours in the US
● Need to adapt to different cultures
● They don’t have a network in your home country, or understand norms
● You need to be very precise (every message must be spelled out)
Pros and Cons of offshore teams

28. Country-wide differences from my perspective
Country Attributes How you should Adapt
India Timid, says yes when they don’t understand,
wants to please
Ask them to tell you how they plan to accomplish
something, if they can’t explain how, they didn’t
understand. Encourage them to give their
feedback
Mexico Very similar culture to the US Give them tasks, make sure there’s clarity, let
them run with it
Israel/Russia Very self-confident, lot of ego. Needs their
autonomy. Will give you all their ideas
proactively, and wants you to adopt them.
Incorporate all their ideas that are net neutral or
positive. Discard a small % of the ideas. Have
fun with them, they’re a lot of fun, build a
relationship so they learn to trust you. Once they
trust you things progress much better.
China Will work very hard without telling you or
taking credit for it. Quiet. Won’t push back
naturally.
Encourage their feedback. Ask their opinions.
Engage them. They will respect and appreciate
you if you make them a part of the decision
making process.

29. How to make it work: Teach and Learn
Learn then teach the developers the business
- Learn the business problems and their solutions
- Teach the business problems/solutions to the development teams, include it in your documentation
- Having a business context will help them make small decisions better, more efficient for both of you
Learn the technology
- If you’re technical, learn how they’ve architected the system. If you can show you understand it, you
will earn more respect from them.
- If you’re not, at least learn what’s easy/hard to do (the purpose of learning the architecture)

30. Have a Clear & Efficient Development Process
Problem - what business problem are you solving
Solution - What’s your process/business solution to the problem (not technical solution)
Designs - let UX/designers/product mock up the solution in detail
Effort estimate / Tech Design - Effort to complete & high level design
Backlog prioritization - Prioritize on impact/effort
Development - Build it
QA/Load testing - Test it
Release it - Release & if needed train the customer how to use it

31. Ensure you have a balanced team
You want to be sure you have the right number of front end, back end, and full
stack developers.
Full stack developers are the most versatile since they can do both front/back end
Encourage full stack development, invest in training them (hands-on)
Ensure you have at least one senior person in front and back end development on
each team! Don’t trust your engineering manager will do this (though they should)
- If not, find a senior person that can mentor the junior resources on your team

32. Clearly document what you want
How do you know you’ve clearly documented what you want? You should be able
to say the following:
1. I clearly defined the business problem and solution
2. I have mockups for all screens/buttons/dialogues
3. I have documented everything at the Object/Field/Value/Functionality level.
That means every piece of functionality is documented, as well as what
button/field/value drives that functionality.
a. This includes actions/expected outcomes
b. Error messages clearly spelled out by a native english speaker familiar with software error
messages
c. What checks should be performed to ensure integrity of the data (data logic)

33. Testing strategy
To maintain a quality product, I recommend the following:
1. Full set of regression tests in shared development environment
2. Full set of regression tests in stage environment
3. Full set of load tests in stage environment
4. Non-creative regression tests in production environment
Anything short of this risks introducing bugs into production with a high likelihood.
This may make me unpopular, but I am not a fan of unit tests - I think they take
more time to create and get right than they add in value - it’s like coding
everything twice. Just focus your effort on comprehensive regression tests
instead.

34. www.productschool.com
Part-time Product Management, Coding, Data, Digital
Marketing and Blockchain courses in San Francisco, Silicon
Valley, New York, Santa Monica, Los Angeles, Austin, Boston,
Boulder, Chicago, Denver, Orange County, Seattle, Bellevue,
Toronto, London and Online