large_Crossover Series NFTs.png

medium_Crossover Series NFTs.png

small_Crossover Series NFTs.png

thumbnail_Crossover Series NFTs.png

From Photography to NFT Art: Twisted Digital Landscapes with Nate Hill

From Design System to ‘NFT Design System’: Creating TinyFaces

Neurodiversity and Inclusion: Choosing Kinder Design

medium_652ccf22c8853584bde5553986a4eed0.png

small_652ccf22c8853584bde5553986a4eed0.png

thumbnail_652ccf22c8853584bde5553986a4eed0.png

Web5 is here. Goodbye Web3? TBD.

<p>Published on <a href="https://blog.prototypr.io/how-we-threw-everything-away-and-released-the-right-product-in-5-weeks-467469c77f7e?source=rss----eb297ea1161a---4">| Prototyping: From UX to Front End &mdash; Medium</a> Chris Nicol </p>
<h3>A little history</h3>
<p>Back in 2015 our R&amp;D team started to work on an internal product to improve cross team and company wide collaboration. This project emerged from staff feedback that pointed out we collaborated really well within teams, but poorly between teams in our company.</p>
<p>The R&amp;D team defined a number of problems …</p>
<ul>
<li>Staff didn’t know what each team’s purpose was</li>
<li>Staff weren’t sure of who does what on each team</li>
<li>Roadmaps and active work were obfuscated within various project management tools and processes</li>
<li>Teams lacked a clear purpose that was connected to the company/product strategy</li>
<li>There was no clear or trusted view of the whole company — the teams or products and their relationships</li>
<li>Teams and products lacked clear metrics that could be used to understand their progression</li>
</ul>
<p>It was a lot to consider, but the team designed an amazing first prototype to tackle these problems. It focused on creating a collaboration tool that would provide transparency and understanding to the whole company. It was an appropriate outcome to strive for.</p>
<p>After the first beta was released to the company, the R&amp;D group started searching for someone to take the product to the next stage. That’s where I came in as Product Manager and started to build a strong team.</p>
<h3>A challenging few months</h3>
<p>Before I took over the product, the team had already started the process of converting what was effectively a prototype to a full product stack. There’s a great deal more to this story, but it’s not completely relevant for this post. I’ll summarize everything by saying that I made two mistakes:</p>
<ol>
<li>Although I looked at the problems, features and outcome of the product skeptically when I first took over the product, I failed to apply enough skepticism and I didn’t listen to my gut when I had more questions than answers.</li>
<li>I didn’t take the time to fully understand the scope of adopting this new tech stack for the product.</li>
</ol>
<p>These two mistakes led to our first few months of work. We rebuilt the prototype as an app on a new stack and added to the existing feature set to solve the major concerns about the user base.</p>
<p>As we forged ahead on this direction, we were making progress and users were excited by the features that we had in development. On the whole, we were doing a good job and the product was moving forward. However, I was often trying to convince myself that we were on the right path as a I talked to others about the vision of the product.</p>
<h3>Change of circumstances</h3>
<p>After a few months, our company started to look at implementing Holacracy, a new type of organizational system. This was a huge change for our team, as it solved a number of the problems that we had been trying to solve with our own product.</p>
<blockquote><p>Holacracy is a system of flat organizational governance trademarked by HolacracyOne, in which authority and decision-making are distributed throughout a holarchy of self-organizing teams rather than being vested in a management hierarchy. — <a href="https://en.wikipedia.org/wiki/Holacracy">Wikipedia</a></p></blockquote>
<p>At first we looked at how our product could be used to implement this system. Then we looked at how we could integrate with Glassfrog, a product for supporting Holacracy.</p>
<p>As we looked at these options, the whole team started becoming more and more uneasy about what we were trying to build. The feeling that I wasn’t 100% confident about the vision of the product, that gut feeling I had before, was growing inside me.</p>
<p>Then a single conversation changed everything. Our VP of Product said something that not only set me free of this product but also reinforced my understanding of the purpose of a Product Manager.</p>
<p>He had been asking a number of skeptical questions to prompt me to think deeper about the product and the outcomes that we were trying to achieve. Then he said, “Chris, I just don’t see you slamming your fist on the table and saying ‘We have to build this product’”. That hit home for me. Those gut feelings, the elephant in the room, that had been there for awhile, coupled with the fact is that I wasn’t convinced that this was the right product.</p>
<blockquote><p>Now, in this moment, is always the best time to build the RIGHT product</p></blockquote>
<blockquote><p>— Danny Robinson</p></blockquote>
<p>I realized that a Product Manager should be constantly evaluating whether the right product is being built. If not…</p>
<h3>Stop, reframe and build it right</h3>
<p>As obvious as that revelation was, it freed to me to throw everything we were building away and reframe. At first I was worried about how the team, stakeholders and users would react to what seemed like a drastic change in direction.</p>
<p>The thing about building the right product is that as soon as you communicate the outcome you’re aiming for others get on board.</p>
<h3>Come up with the right product (together)</h3>
<p>Once the decision was made, the team needed to work with users to come up with what the ‘right’ product was. We immediately jumped into a design sprint. We worked together to reframe and clearly define the problems that needed to be solved<strong>.</strong> After the introduction of Holacracy, we were able to eliminate a number of problems that were solved by Holacracy and focus in on the problems that still existed. We then iterated on ideas (diverge and converge), built out prototypes and finally tested to learn.</p>
<p><a href="https://www.tandemseven.com/experience-design/ux-agile-run-product-design-sprint/">UX and Agile: How to Run a Product Design Sprint</a></p>
<p>This was a rewarding and productive process. As a team we hadn’t paused to do this, even at the beginning. We had inherited a Product and just jumped right into building it out (mistake #1 from before). As a team, we were galvanized around our vision. With the introduction of Holacracy, circumstances had changed. The vision of the product needed to as well. Users didn’t need a collaboration tool any longer. What they needed was clear reporting on the work that was going on and metrics for teams . That was still an undeniable problem for the company and our users.</p>
<h3>Constraints to delivery</h3>
<p>We had a vision, one that made me want to slam my fist on the table and say “We have to build this product”. The next step was to actually build it, and fast. We did have some natural constraints though that helped. Holacracy was being rolled out company-wide and the executive team wanted a renewed focus. Our product was a key part of this renewed focus. Also, I was about to leave on sabbatical in a few months. My goal was to utilize these constraints to ensure that we delivered value in a short period of time.</p>
<p>These constraints helped everyone on the team, especially me, to focus on delivering on the vital aspects of what we needed to solve the problems that we had defined and validated. We prioritized through buying and reusing rather than building. We focused on the the clear vision that we shared allowed us to focus on the task at hand. You can never underestimate the value of focus when it comes to delivery, especially with a team.</p>
<h3>5 Weeks</h3>
<p>From the moment that we started the design sprint to our first release was just five weeks. We had thrown away the original product. This wasn’t because the R&amp;D team, or our team, had built the wrong product, but because it wasn’t the right product for the current needs of our users.</p>
<p>That was merely the first release. Over the next couple of months we added features and hardened our app. Within our constraints we delivered the product that we set out to deliver (with some changes arising from feedback loops). We delivered the right product.</p>
<p><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*gRvtJD2Vwh6h-B-X9VNySg.png"></p>
<h3>But was it the right product?</h3>
<p>Do I know for sure that we built the right product? No, I don’t. Right now I’m on my sabbatical. When I get back, I’ll <strong>review</strong> the data. I’ll interview users and stakeholders. This is the only way we’ll find out if the product we built has led to the outcome our users needed.</p>
<p>What I do know is that I’ll never hesitate to let data and users correct my understanding of what is needed. I will forever focus on building the RIGHT product.</p>
<p><img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=467469c77f7e" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou"></p>
<hr>
<p><a href="https://blog.prototypr.io/how-we-threw-everything-away-and-released-the-right-product-in-5-weeks-467469c77f7e">How we threw everything away and released the right product in 5 weeks</a> was originally published in <a href="https://blog.prototypr.io">prototypr</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>


How we threw everything away and released the right product in 5 weeks

How we threw everything away and released the right product in 5 weeks

A little history

Top Stories