Releasing Software as a Team

Close to a year ago, I was given the chance to join the Blockchain Team. After I was fully on-boarded, I took a couple weeks to attend every product and engineering meeting. Not that I was involved in the on-going projects but to see how the machine runs. Blockchain is the largest company I’ve worked at historically being at early stage startups ~10 employees. The last thing you wanna do as a new hire is bull dog your past work experience into the culture.

I could see that product moves quickly and learnings + insights on the decisions were getting lost during hand off. I took sometime to propose an end-to-end product development doc. After I had a draft, I shared it in our team chat. I gotta admit it was nerve racking to send my idea to 150+ people given we can’t edit our slack messages for legal reasons. There was no “Oops! Wrong chat. Delete message.”

Every team member was encouraged to review, edit and ask questions. What we have below is an idea on how we can improve release rate velocity and documentation of decisions.

We’re close to this process today. Note: I do personally opt to just send designs to dev if the change is small or does not need to interrupt the current sprint 🙃

This doc has been sitting around so we’re sharing with the hope it might help your team, or give anyone new to product, insights on how software can be built. It gives a broad overview of steps and definitions. Given an entire company helps to build a product, we wanted to share what we landed on as it might help your crew — grant clarity and understanding to you and the people helping build your latest project.

I’m sure this doc is missing a few points. All processes are fluid. Granular changes and experiments as you fine tune. Changes are OK and welcomed.

I wanted to say thank you to the Crypto Crew below for taking time to review and incorporate each of their past experiences and individual understandings of product development best practices.

Adam Zaki // Product Owner
Andrew Schneider // Front End Web
Autumn Veigh // Product Design
Chris Arriola // Head of Mobile
Franklin Weldon // Product Owner
Katie Wells // GM
Kevin Wu // iOS
Mikael Keussen // Product Design
Rosana Castano // Product Design
Thianh Lu // Head of Product Design
Tony Popov // Full Stack Eng

Goals
1. Ensure clarity at every point of product development.
2. Are we creating a meaningful experience truly solving our customer’s needs?

Roadmap
This is your company’s roll out plan. Is it up to date? Probably not. Do curveballs come in? Always. The basic company strategy expecting business change, fires (when software breaks) and any sort of course correction.

Product Owners
For every project, it should be clearly relayed to the company who owns which part of the project. This arms information seekers with avenues of success they need to get the answers they’re looking for. This also keeps attention redirection low.

Marketing
Design
Engineering
Product Owner and/or Manager

Business Objectives
What problem are we solving?
Have customers been vocal about this?
What’s our measurement of success?
ex: Increased Customer Satisfaction, Lowering Attrition, Increased Revenue

Project Requirements
Once we know the problems we are aiming to solve, we can review our existing products and develop a list of project requirements. These should be outlined with a direct metric to hit or a general question to solve. Let the team figure out the solve.

Define Stakeholders
These are the people who have requested we investigate and complete the project. They give the go or no on the launch of the project. These are also the men and women you reach out to get clarity on the project. It’s OK to ask “Why are we doing this?”

Define Scope
AKA Scope of Work, get Product Owners, Product Managers, Department Heads and Tech Leads all together to define what it takes to get the project done. This includes technical dependencies, 3rd part integrations and each team’s capacity plan — the human power.

Write Up a Project Brief
This is our best assumption at achieving success. Yes I said assumption — that’s what it is. A hypothetical solve to a perceived problem. The Project Brief is a boat launch exercise. Here’s where we wanna go. You’re on open water. Get there however it works best. While each team works differently, they research, conceptualize and present to each other solves that might match the brief other than expected.

1 // Kick Off
A kick off allows the problem to be presented, project brief to be distributed and each department present to get on the same page. At this stage, the more the merrier. Let’s get as many brains thinking about this problem as possible. Not a single pixel has been placed or line of code written. All ideas are welcomed and encouraged — but during in this meeting. Take time to digest and present back to the team once you’ve thoroughly thought it through and you’re still excited about the idea / solve. It all comes down to collaboration.

Product owners should provide user stories. Design can begin to think about customer needs and product impact. Engineering can map out dependencies taking into account what is already live.

Recap
What’s the goal?
What does success look like?
What’s the problem we’re solving?
How do we assume we can solve it?
We believe that [ show crypto market rates on app load ]
For [ any user ]
Will [ make users feel more connected to the pulse of the crypto ]
When does it need to be live?

2 // Stories + Engineering Audit
Ticket Status = None
Project dependencies have been assumed for the tech stack. Back End can now audit their existing tech and 3rd party solutions to ensure end points are ready. This is a bit of a wash area pending the design solution. Most likely, a new end point(s) will be requested via Design’s solve. Product Owners to create full feature architecture scheme based on the user story. That is platform, micro services and 3rd party services.

Recap
Auditing the current stack, what do we need to build?

3 // Design Backlog
Ticket Status = Ready for Design
Now with a brief ready, the Product Owner or Project Manager writes up stories to satisfy the project. This brief is to get the solves started. Not words to live by. Just a starting point.

If I’m a verified user
and I’m logged into an active session on web
and I own multiple crypto assets
show me my portfolio change and market change

4 // Design Takes Over
Ticket Status = In Design
Armed with the brief, Design reviews the stories and begins research on competitors who have already solved this and/or common design patterns to be pulled from. At Blockchain, we don’t see UX and UI as 2 separate roles. We believe a Product Designer is responsible for anything customer facing. A strong understanding of platform best practices and a great visual taste. As the Design team work through the project, they are doing internal presentations. The solves should be shared with the PM & Engineering leads to make sure we have endpoints ready or in the works. No reason for Design to work in a silo. Once the logic and visual is signed off via the design team, the work is presented to stakeholders. If all looks good, send to dev.

Recap
Does the art satisfy the brief?
Did we add any new end points?
Do the designs match or beat the release deadline?

4 // Into the Backlog
Ticket Status = Ready for Dev
The ticket has been updated with production ready assets and links to screens/flows. The designer who passed off the ticket is responsible for ensuring the engineering teams understands the work to be done. A quick walkthrough is highly encouraged. UX bugs will often be found at this point which is great! It’s on the engineering team lead to assign the ticket to the engineer who’s capacity plan can fit in the work.

5 // Begin Development
Ticket Status = In Dev
This is where things start coming together. Engineering staffs up on the project. Breaking it down where appropriate. Is it an iOS project? Get an iOS dev on it. During development, keep the feedback loop small. Engineering should share the progress often with Design. Most of the time, engineers discover smalls wins breaking the initial designs. If you’re a designer, lean on these proposals.

6 // Dev done. Needs Design Review
Ticket Status = Ready for Design QA
At this point, the dev work has been pushed to staging. Design is to review the work to ensure it solves the stories. This step loads up the Design team with work to be QA’d. This helps with context switching as you can assume they’re deep in other areas of designing.

7 // Design QA Begins
Ticket Status = In Design QA
The dev’d work will be QA’d with the art side-by-side. The Design owner if not entire Design team gets a build and fine tunes — copy, tries to break it, find unforeseen edge cases, micro interactions, etc. Note: Don’t worry about pixel perfection or animation timing. Polish at the end. And don’t worry about copy. It’s going to change.

8 // Let’s Test!
Ticket Status = Ready for QA
Once Design signs off, QA (Quality Assurance) can get to testing. Again, this step is give the QA team clarity on what needs to be tested. The ticket has the designs, stories and all comments. They can fully comprehend on the problem to be tested against and how it was prepared.

9 // Test the code.
Ticket Status = In QA
Smoke and Regression Test. This is a functional review. Does anything break? It’s tested against what is already live.

10 // All looks good
Ticket Status = Ready for Release
Product Owners are notified that the ticket / build has passed. Most of the time, a staging review with the kick off team works well to say “Hey we did it!” Next is to prepare cutting the release. Depending on the platform, timing and release notes are prepared. The new new is ready.

11 // Done and done.
Ticket Status = Closed
With a ticket closed, we have historical view on all work completed.

Boom! You did it!

Your team went from a problem with no visual or engineering to a fully functioning feature, bug fix, or brand new product. Celebrate this. You need to high five with your team. Publicly praise who you worked with. You can do sprint after sprint after sprint but if there are no breaks for camaraderie, what’s the joy in working together? Oh and be sure to test if it’s helping or hurting. If metrics are going down or those bad app reviews are coming in, analyze and iterate. Software never ends.

How to report a visual bug.

A simple How To on reporting and communicating design bugs.

Feedback is welcome at all time. Feel free to create a ticket or slack the Product Owner.

First, take a screenshot! A visual reference is a your best friend.

iOS / Android
Device screen shot. Button combos varies by Device and OS

OSX
CMD+SHIFT+4
CMD+SHIFT+5 to record a video
CMD+SHIFT+5 during recording to be able to stop

Windows
Windows Key + PrtScn
or Snipping Tool → Start → All Programs → Windows Accessories → Snipping Tool

Now that you have a visual reference, what’s up? In your ticket/message, please concisely write how you believe this is wrong or could be better. If you believe the bug is a result of your recent workflow, please write a quick story to help us reproduce the steps. Along with any visual bug, please take a stab at providing a solve for the issue.

Also relay what build, device, OS and Browser (if applicable) was in use.

Example Visual Bug Report

Story
While logged in on web,
and I click Exchange,
and my browser window is very wide,
The Exchange UI stretches full screen width

Reference
Attach a screenshot or video.

Suggestion
This looks odd on large screens. Maybe give the container a fixed-width?

System
Web Build 14.1.2
OSX 10.14.5
Chrome 74.0.3729.169

Follow us on twitter @blockchain. If you ever wanna chat Product Development, Design, or Crypto, find me on the twitters via @gregchristian. Lastly, we have 50 job openings heavily on the Engineering side in 5 offices from San Francisco to London. Find your fit here.

📝 Read this story later in Journal.

👩‍💻 Wake up every Sunday morning to the week’s most noteworthy stories in Tech waiting in your inbox. Read the Noteworthy in Tech newsletter.