PWI Development Process

Define the objective. Objectives must:

• Be measurable

• Be realistic

• Have a proposed deadline that is attainable

  • This deadline can be proposed by a VP, but the software team must verify that it is attainable and commit to it.

Meet with key players to determine the problem statements and scope.

• Key players include people who will be using the feature, and people that are telling us the feature is necessary.

• These can be 1:1 meetings, or group meetings. Group meetings should always be initiated with the consent of green or red level managers.

• Be sensitive of the time you spend with this. You want to get the feature right, but don't want to spend excessive company time. Make sure these meetings have a defined agenda, and that you keep them moving.

• Focus on gathering ideas from end users, or people that have insight into what end users want.

• Ask coworkers (from our team) to help you gather problem statements if needed.

Narrow/review the scope

• End users should be heard, but not always listened to

• Managers should have input on scope, especially in business-critical functions

• Review scope with your supervisor if you have not done so already

• (larger projects) Make sure you have reviews from outside our team

• Remove or table ideas that fall outside what is realistic

Develop a timeline - what needs to be done first? What belongs in the MVP?

Build any proof of concepts (POC) needed

• Build a "quick and dirty" POC for features you aren't sure about

  • Plan to discard this POC

  • This helps you identify the challenges you will face during the build phase, and helps you get better estimates of timelines

  • See this PWI University lesson for more info

• Use peer-review to make sure the POC works as intended

Define wireframes if needed

• No wireframes for Stacker or other similar no-code platforms

Scope out MVP

• Decide what is needed for the MVP

• Define a timeline for MVP, and any development phases that you know we need after the MVP is released

• For large or business-critical apps, meet with the appropriate VP to discuss the MVP timeline and features. We need to keep them in the loop.

VP Review

• If you haven't relayed the expected MVP timeline to the appropriate VPs, do that before you build.

• Give the appropriate VPs a quick rundown of the features of the app

  • If you have any questions about the value of or need for a certain feature, run it past the VP before building it!

Build

• Build the MVP

• If extensive testing is necessary, decide who your alpha and beta testing groups will be

  • Keep the alpha group very small and choose only highly technical people

  • Choose people that will be able to "test" and not just "use" the app

  • Choose people that will have good insight into what may be useful or missing

  • Choose people that can follow instructions

  • If testing will be done during work hours, make sure their managers are OK with their involvement

Test

1. Alpha test with peers - get help to work out the kinks

   • Edge testing - find the weirdest scenario that might actually happen

     • Example: in a calendar, what if an event lasts 4 months?

     • Example: in a stairway, what happens if someone orders a top landing that is 40ft long?

   • Chaos testing - Put in values that you know will break it

     • Example: Put negative values into number fields

     • Example: Put end dates before start dates

2. If beta testing is needed, start beta testing when the majority of the MVP functionality is ironed out (80%+)

   • Beta testers are a valuable source of missing user stories. Almost all feature requests that come up during beta testing should be implemented, but not until after the MPV release. The exception is critical/blocking issues with the current functionality.

Review and demo functionality with appropriate vice presidents. In other words, make sure the boss likes it.

Release to small group for final proof (beta + gamma testers)

• The canary group should be comprised of the beta testers alongside of some "normal" users

• The goal is to find any areas where the workflow is unclear, or the UI is not intuitive

  • User isn't sure what to do next

  • Words are misspelled, or wrong words are used

  • Placement of controls doesn't feel natural

• If the final user base is small (5 or fewer) you can release to everyone.

Implement feature requests that were brought up during beta testing

Fix any bugs that come up

Release to everyone

• Provide 1:1 training for the initial users

• After initial users are trained in, create documentation or training materials for future users

Monitor and check in with users regularly for 3-6 weeks after release to ensure smooth operation

• We don't want to abandon our end users with an unfinished project

• Use 1:1 meetings instead of emails or surveys to build rapport and see it from their perspective

Prioritize bug fixes for the first 3-6 weeks

Repeat steps 3-5 as needed for additional development phases