Measuring how hard your team is working by counting the number of hours they work or what time they get in and leave is how amateurs run companies. The number of hours worked is not the same as how effective they (and you) are. I had been invited by Rahul, one of my students from […]
Here’s how we’ve organized traditional schooling: You’re certain to have these classes tomorrow. The class will certainly follow the syllabus. There will certainly be a test. If you do well on the test, you will certainly go on to the next year. If you do well on the other test, you’ll certainly get to go…
I am fascinated by the process that went behind building the products that I use every day. Spotify is a company that has an awesome track record of product delivery with over 20 million active users and 5 million and growing paying subscribers. Spotify’s core phases for Product Development are as follows:
- Think It = figure out what type of product is being built and why.
- Build It = create a minimum viable product that is ready for real users.
- Ship It = gradually roll out to 100% of all users, while measuring and improving.
- Tweak It = Continuously improve the product. This is really an end state; the product stays in Tweak It until it is shut down or reimagined (= back to Think It).
The following chart shows the Risk vs. Time for each phase:
As you can see, the “Think It” stage drives down risk at a low cost. You can also see why the “Build It” phase is short as possible (high operating cost and little risk reduction). To gradually reduce operating cost in “Tweak It” reflects that, over time, the product doesn’t need to be updated as much and teams can start moving on to other things.
In addition to their product development process, Spotify also has a unique approach to how they organize their teams into their Goal Focused Squad model. The following video goes over how Spotify organizes their teams:
You can also read more about Spotify’s Product Development process here.
I’m a huge fan of the Lean UX methodology when it comes to solving problems and building better products. Another book that takes the whole Lean UX methodology to the next level is Sprint by Google Ventures. The book offers the same themed day approach where a five-day process leads to answering crucial questions through prototyping and testing ideas with customers. A typical week using the Sprint approach looks like the following:
The following playlist goes over each day of a Sprint week and what makes the process special:
“We’re making a long-term bet that immersive, virtual and augmented reality will become a part of people’s daily life.” – Marc Zuckerburg
This past week I had the opportunity to try out the HoloLense at Microsoft Build in San Francisco. I was overall impressed by the experience. Having also experience the Oculus Rift, I found the HoloLense to have way more practical use cases other than gaming and entertainment. As with any new technology, the HoloLense still has a long way to go to be ready for the mass consumer market but it’s great to see Microsoft thinking ahead and innovating towards the next platform after mobile.
The following video goes deeper into some of the possibilities of Hololense:
In Lean UX, the starting point is having a clearly written hypothesis statement. This gives your entire team a clear focus for their work. It keeps everyone aligned and sets the right constraints. In order to arrive to a well written hypothesis statement here are some of the steps:
- Declare Assumptions – A high-level declaration of what is believed to be true.
- Hypothesis – Specific descriptions of assumptions that target your product
- Outcomes – Metrics that can help validate your hypothesis. These can be both qualitative and quantitative
- Personas – Users for whom we are trying to solve the problem
- Features – The product changes or improvements that may solve our problem
First, based on specific user and business assumptions you want to write a problem statement using the follow template:
[Our service/product] was designed to achieve [these goals]. We have observed that the product/service isn’t meeting [these goals], which is causing [this adverse effect] to our business. How might we improve [service/product] so that our customers are more successful based [these measurable criteria]?
Next, you want to come up with some user assumptions by asking the following questions along with your team:
- Who is the user?
- Where does our product fit in hi work or life?
- What problems does our product solve?
- When and how is our product used?
- What features are important?
- How should our product look and behave?
After stating the assumption for both your users and prioritizing them based on level of risk. The final step is to write a hypothesis statement using the following format:
We believe [this statement is true].
We will know we’re [right/wrong] when we see the following feedback from the market:
[qualitative feedback] and/or [quantitative feedback] and/or [key performance indicator change].
Most of the time the main hypothesis can be hard to test when building out specific features. To break the hypothesis down further, you can create sub-hypothesis to test specific features using the following format:
We believe that
[doing this/building this feature/ creating this experience]
for [these people/ personas]
will achieve [this outcome].
We will know this is true when we see
[this market feedback, quantitative measures, or qualitative insights].
Once your hypothesis statements are written. The next step includes deciding on the Key Performance Indicators that can validate your hypothesis for each feature build. This should again be done collaboratively. I’ll talk more about how to determine the right KPI to measure success in the next post. Stay tuned!
How do you practice Lean UX when you have teams in different time zones and different locations? Implementing a Lean UX product management practice definitely works better when your team is in the same office but it shouldn’t be an excuse if your have teams in different cities across the world. Jeff Gothelf, the author of Lean UX, shows how teams in different office locations can still take advantage of the Lean UX process. Moreover, he shows why product management teams need to get out the deliverables business and start creating shared understanding within their teams: