Recently, I've had the opportunity to pair with a very intelligent and hungry individual, bringing her up to speed as a Product Manager on a software project. She has a background in the public sector, administrative and technical, but not a "Developer", "Programmer", "Engineer" by trade. Basically, no prior product experience.
We get to work together and I get to share tips and tricks; experience I've gained building software tools and managing systems. We cover high-level concepts, perhaps sometimes philosophies - but also are looking at fine grain interactions within and between screens, across devices.
And, I've been giving a lot of thought to microinteractions. Probably the wrong word. But, I do many small things in the course of software development and product management. Working with a student encourages me to be more explicit with what I do and why I do it. I'm rewarded because the process of pairing reveals and filling gaps in my own knowledge.
I wanted begin a list of Common Tasks I perform and the microinteractions those Tasks are composed of.
Fixing an Image on a Website
- Open Sketch
- Open the file
- Edit the image
- Save/export the image
- Move image to the proper path within the project
- Update the code in the project
- Save the code
- Commit the code
- Push the code
- Watch the code CI
- Watch the code deploy
- App is deployed and image on the website is fixed
Grooming a Backlog
- The goal is a prioritized list of groomed Stories
- Prioritize by business value
- If supporting multiple devs or pairs, consider multiple tracks of work
- Learn your team's strengths and filter work accordingly
Emitting Work
Often, when building a product, it becomes necessary to communicate to people beyond the team building the product. Stakeholders, sales, support, marketing, and of course, Customers.
At times, it is beneficial to keep a running log of work. Sort of like I'm doing now. I think of this as meta-work.
Documenting the what and why of a project helps for sharing and building a broader understanding and dialogue around products and experiences. Artifacts like documentation, screen designs, product slides, become proxies for feedback that allow you to learn even more.
The Product Cycle
Keep an eye open for places where you can re-use and leverage certain points in the Product Cycle, like how "Personas" are used in every "Use Case". At least one automated Test should exist for every Use Case. How Screen Designs represent an ideal future state of the application, where screenshots of the current application represent reality. The Backlog should pave the path between Current State and Desired State. Nearly every software product is subject to this general cycle.