O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

How to Best Develop a Product by PlateRate Founder

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Carregando em…3
×

Confira estes a seguir

1 de 34 Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Semelhante a How to Best Develop a Product by PlateRate Founder (20)

Anúncio

Mais de Product School (20)

Mais recentes (20)

Anúncio

How to Best Develop a Product by PlateRate Founder

  1. 1. www.productschool.com How to Best Develop a Product by PlateRate Founder
  2. 2. FREE INVITE Join 30,000+ Product Managers on
  3. 3. COURSES Product Management Learn the skills you need to land a product manager job
  4. 4. COURSES Coding for Managers Build a website and gain the technical knowledge to lead software engineers
  5. 5. COURSES Data Analytics for Managers Learn the skills to understand web analytics, SQL and machine learning concepts
  6. 6. COURSES Digital Marketing for Managers Learn how to acquire more users and convert them into clients
  7. 7. Garret Lang TONIGHT’S SPEAKER
  8. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 25. On Working with Offshore Development Teams Garrett Lang
  26. 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. 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. 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. 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. 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. 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. 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. 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. 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

×