Plan with Pinch

The Pitch The Big Idea 5-15 Minutes

"What are we doing?" All projects and products are born out of an idea, chances are you have assembled a group of people that are like minded in helping you build something you already pitched to them. Let's get everyone on the same page and announce to them all what the intention of our build is going to be. "I want to build a product that does _____".

  • Share your idea with the team, get some buy-in.
  • Timebox your effort, there should be a short deadline.
  • 2-10 Working Days is the recommended timebox for Pinch. Longer projects will benefit from more robust planning.
  • Choose someone in the team to facilitate Pinch.

Value Proposition Validate 5-15 Minutes

"Is this a project or a product?" While all projects and products start with an idea, products actually have to be valuable to some identifiable market. If you want to build a product, you owe it to yourselves to find your value proposition.

  • Start thinking about your potential customers. Who are they?
  • What problems do they have? What benefits do they want?
  • How will what you are building be valuable to these customers?
  • Find your value proposition.
  • Draw two intersecting circles (venn diagram).
  • In the right circle, define your customer.
  • ex. "Tech Savvy Entrepreneurs"
  • In the left circle, define what you intend to offer the customer.
  • ex. "Theory and framework that expedites planning and delivery of products"
  • Once complete, find your value proposition by matching your customers to what you are offering.
  • Value Propositions can be simply worded at first:
  • "Our product helps tech savvy entrepreneurs plan and deliver working products quickly."
Value Proposition Model

MVP Statement MVP Statement 5-15 Minutes

"What's the least we can do?" Now that there is clarity about what we are building and who we are building it for, it's time to identify the Minimum Viable Product. For Pinch, your MVP statement needs to be a short walkthrough of your product from a client perspective.

  • Take for (unimaginative) example, you want to build a typical digital purchasing experience:
  • "Our clients need to be brought to our store, see products, put products in a cart, register, join a mailing list, pay, and be able to download products."
  • Once we have the MVP framed out, we need to challenge it. "What can we take out, and still be viable?"
  • Chances are, you don't need a marketing campaign or mailing list at first, so cut it. Cut anything you can.
  • Our MVP now becomes:
  • "Our clients need to see products, put products in a cart, register, pay, and be able to download products."
  • Write that MVP down, it's your goal and we're going to need it.
Minimum Viable Product Statement

MVP Breakdown MVP Breakdown up to 1 Hour

"What's the least we can build?" That fancy MVP statement we just made needs to be broken down into workstreams. The best way we have found to do this in physical space is using what we have affectionately named the "Gravity Board".

  • Take the MVP statement:
  • "Our clients need to see products, put products in a cart, register, pay, and be able to download products."
  • Identify your workstreams, or major components of the product:
  • "Our clients need to see products (store), put products in a (cart), (register), (pay), and be able to (download) products."
  • Start your Gravity Board grid with your workstreams as columns:
  • Store | Cart | Register | Pay | Download
  • Draw long vertical lines downward between your workstreams.
  • Draw three horizontal lines under your workstreams, about 12 inches apart. You should be left with a nice grid having three rows under each workstream.
  • In the top row, under each workstream, use some Post-its and start to break down the tasks required to deliver that workstream. This can be done one workstream at a time, or concurrently, so long as it's done collaboratively.
  • Under our sample "Register" workstream, we might see some tasks like:
  • Define what client info is required
  • Define what client info is optional
  • Build model
  • Build web form
  • Registration logic
  • Validate and test
  • Return URL
  • Form Validation
  • Input Sanitizing
  • Error Handling
  • After you have a good representation of the work, everyone should challenge the plan and find what isn't absolutely necessary. Any work that can wait should be removed and implemented at a later time. While all of the above is what's going to expected when you go to market proper, you might not need it all right now. Agree among your team what you are willing to sacrifice, and maybe end up close to this:
  • Define what client info is required
  • Define what client info is optional
  • Build model
  • Build web form
  • Registration logic
  • Validate and test
  • Return URL
  • Form Validation
  • Input Sanitizing
  • Error Handling
  • Continue to breakdown each workstream of your MVP.
  • Challenge as you go and make sure you are only doing the most important work, and only just enough of it.
  • When everyone is satisfied that we have a plan that represents the least to be done, ask among the team who will become the "owner" of each of the workstreams.
  • The owner should write their name at top of the workstream, and become the "go to person" with questions and problems.
  • This in no way suggests the workstreams are idividual efforts (no silos!), everyone should work as collaboratively as possible. We just need to recognize the strengths, weaknesses and desires within our teams. Builders will gravitate to work that excites and challenges them, it's best to let them have some ownership of it.
MVP Breakdown MVP Breakdown MVP Breakdown

Tech and Tools Technology and Tools 5-15 Minutes

"How are we doing this?" Everything is shaping up with the plan, now we need to look at what we are building and make the best decisions possible about the technology and tools we will use based off of what's available to us, the teams experience with popular tools/languages, and what's best for our product.

  • If you are delivering software: define your stack, languages, and budget.
  • I've got a list of some of the best free/cheap options out there.
  • If you are delivering a physical product: define your tools, materials, and budget.
Tech Stack

Planning is Done. Time to Build!

At this point, you should have a Goal, Workstreams, Tasks, Tools, and Team ready to go!

Build with Pinch

MVP Burndown MVP Burndown Until the clock runs out, or you're done.

"Maintain transparency, value communication." Now comes the hard part, delivering working product on a tight timeline. There are going to be complications along the way, trust in each other and communicate quickly to resolve them. We're aiming for functional and valuable, not refined and polished.

  • The Gravity Board has three rows setup. All those tasks on the top row are "ready" to be built.
  • As you chose work to do, move the related task(s) into the second row, to signal to the team that they are in "build".
  • As you complete tasks, and start to see pieces of the product function, let your team know verbally and by placing the related task(s) in the bottom "done" row.
  • The team might want to validate your contribution, let them!
  • As the last task for each workstream moves into the done row, the team should validate that the new feature of the product is functional.
  • Repeat until the product is complete, or you run out of time.
  • While the product being complete speaks for itself, your Gravity Board may have some lingering tasks. If this is the case, double check that things are up to date and you are not missing MVP features.
MVP Burndown MVP Burndown

Deliver Deliver It's Alive!

"Welcome to Parenthood!" As your effort winds down, we hope your team got what it wanted.

  • If you have an external client or stakeholder, demo your results.
  • Even if you don't you should have an end to end run through with your Pinch Team before you wrap up if only for some closure.
  • If you didn't quite complete in time, take note of what's left to do (snap a pic of your Gravity Board). Talk to the team and see if it's worth a deadline extension to carry on.
  • Learn from what you produced.
  • Did you get the product you intended to build?
  • Now that you have working product, how would you improve it?
  • Decide if your product will live on and iterate. Assuming it does, you should look into more robust planning and development life cycle.

When the MVP is delivered, Pinch is over.

Thank you for giving Pinch a try, we hope it was valuable to you!

Intro: Pinch is a mindset and a framework.

Pinch Mindset

The Pinch mindset is a mix of core Agile values, augmented with a few new ones. While all of the values of Agile hold true in Pinch, not all of the principles make sense. Agile principles like iterative delivery, sustainable development, technical excellence, and meaningful retrospective all routinely get sacrificed in the rapid delivery workspace where Pinch thrives.

Let's look at the new values Pinch offers in return. Like Agile, we value all of these things, but we value the things on the left more.

Constraint over Commitment

Pinch is going to gravitate towards the entrepreneurial space, commitment really isn't the issue when you bring a bunch of motivated artisan/entrepreneurs to the table. Passion has to exist. Everyone's going to be bought in and working hard to get something delivered, it's going to be more important to constrain their efforts for maximum results.

Momentum over Continuity

The execution of Pinch and your MVP is finite. There is maximum value to be gained from getting everyone to jump in and just start executing. There is no perfect here! When deciding between what is right for now and right for long term, always choose the prior. Everything except the MVP in your hands at the end of your Pinch is 100% disposable.

With hard work and a little luck, your MVP will be something worth going to market with. When that happens, you owe it to your product to adopt a more sustainable, iterative methodology than what Pinch will give you. Pinch is not for long term growth of your project.

Forgiveness over Facilitation

Pinch thrives in the experimental space. We're going to need some permission to fail, so long as we agree that we fail fast. Pinch offers us a framework and we do our best, but things sometimes go south anyways. When it does, get your team together, address it, refactor, and move on.

Co-building over Collaborating

Working and talking together is part of any healthy team, beyond that is the ability to build together. In the entrepreneurial space, you're probably getting to be choosy about who you work with, so challenge everyone to redefine their standards of a high-performing team. Pairing, swarming, doing whatever is necessary so that each workstream is delivered and functional is an extension of collaboration that Pinch demands. The cross-functionality of your team is only limited by your motivations to be exactly that.

Product over Pitch

Great ideas are the start of all great products, great promotion not so much. So long as you know you have a market to serve, focus on the build. Marketing can be a part of your Pinch, but not at the sacrifice to the goal: working product.

The mindset and framework of Pinch combine to provide a "Pinch of Agile", in an arena that Agile has not championed yet: micro-production.

Valuable Resources

A short list of "bang for your buck" tools to build with. If you know of more, let us know!

About: Pinch

Pinch's roots go back to the start of 2013, when Brendan Wovchko came to me with an idea to build some process around rapid building new products. Having recently attended several hack events and start-up weekends, Brendan was looking to introduce some organization and agility to the world of rapid development. I was intrigued when he told me of the troubles that artisan-entrepreneurs have when coming together to build something quickly.

Having come from a development background, I asked myself what I would do if I went to a startup weekend or other condensed project building space without any guidance. I envisioned myself hearing a pitch, getting with a team and just starting to work as fast as I could. It would be natural to set aside all of the hard learned lessons of project leadership over the years and just death march. This is what these otherwise responsible builders have been doing when coming together to build their own products for their own benefits.

With that in mind, I committed to working with Brendan to build a framework that would help them plan just enough that they understood what success looked like and have enough transparency to measure that success. In Brendan's words "It's like we need a pinch of Agile" . With that, we knew what to call it.

I worked over the early part of the year to establish some minimal techniques and exercises, as well as comparing my findings and assumptions against the Agile Manifesto. I found that there was much, but not perfect alignment. Upon review, Brendan and I agreed to adopt some new values to set teams up in the right mindset.

With all of this work and theory in motion, we grew eager to share. With that, we pondered "How do we actually try Pinch?". We knew we needed a team willing to build something for themselves, but entrusting us to help lead them. Those opportunities don't come often, so we targeted the next building event: Hack Nashville 3.

During the intro ceremonies, Brendan introduced me around to a few of the builders in the community. An idea was pitched and a few of them took notice of it. I asked to be a part of it and offered some leadership experience (as well as some UI help). We recruited from around the room and found our team. This would become the Precru.it team, and their story is shared here.

The early iteration of Pinch with the Precru.it team was an absolute success. Feedback was excellent and we were both thanked for the help and organization. We had some adjustments to make, but the results of the build and delivering the MVP successfully was such a great win for us and Pinch.

While we had some proof, we wanted to refine and retest before scaling Pinch out irresponsibly. Brendan contributed greatly in the coming months by getting artisan-entrepreneurs lined up for a second experiment for us. I spent much of my free time over the summer documenting and refining so that we could scale Pinch out a bit more.

With revision in the rear view, October 2013 brought Hack Nashville 4 and new team members to us. I was so excited to get back in and implement Pinch that I didn't even care what the product pitch was. Builders swarmed around Brendan and the ideas started to flow. I helped organize people around the work they were interested in and set up teams. There was much interest from the builders in organizing before they built. If I could do HN4 over again, I would have been more prepared to help them all.

Knowing I couldn't run Pinch on three teams at once, I constrained myself to helping a team that was building a product interesting to me professionally: Review. The Review Team's story is shared here.

While I feel we didn't initially cut enough scope before building, Pinch was again a success in delivering valuable product for the Review team. Feedback was excellent and we were again thanked for our leadership contributions.

With months of collaboration and validated results behind us, Brendan and I agreed it was time to share Pinch with the community. We are actively seeking opportunities with Pinch Teams to help new products and new companies evolve. The story of Pinch continues, share your experience?

MVPs built with Pinch

Precru.it

"Precru.it" is a web application that allows recruiters to monitor public facing Linkedin activities of leads they are interested in passively following. Should status updates that signal opportunity occur, the recruiter could then reach out and introduce themselves at that moment. Precru.it is all about reducing unwanted recruiter interactions until such a time that job transition signals are out there. We get recruiters to the right people at the right time.

precruit precruit

Built at Hack Nashville The Result: MVP Complete
100% Complete

With only two days to build, we asked the team to join us for a quick planning session. We ran through an early iteration of the Pinch planning process in about an hour and a half then retired for the evening. During the next two days, we burnt the entirety of our Gravity Board down. The Linkedin API was finished about an hour before the end of the event, and the entire team tested the product end to end.

Precru.it was demonstrated live, end to end at Hack Nashville 3. The MVP demonstration consisted of: customer registration, (demo) payment, application access, adding linkedin profiles to the application, and receiving real time updates for linkedin members you are tracking outside of your network served via the linkedin API.

Precru.it has remained in a quiet beta state since Hack Nashville 3. It was discovered during the build that API restrictions would hinder the scalability of the product, threatening the business model. The founders have not announced intention to pick the product back up at a later date.

Precru.it Team / Founders:
Kyle Williams · Jesse Gray · Sam Pepose · Brendan Wovchko · Cory Hughes · Dustin Pate · Abe Music · Karlkim Suwanmongkol · Mykas Degesys

Review

"Review" is product demonstration software delivered via Google hangout that allows product teams to demonstrate their products or projects in a fully facilitated environment. Features to control who is presenting, channeling audience feedback,and capturing everything from release notes to user input are being implemented now. Users will also be able to contextually review their entire demo and feedback via private youtube.

review presenter screen review homepage

Built at Hack Nashville The Result: MVP Complete (after scope cut)
85% Complete (success)
100% Complete (warning)

The timebox of hack day is a beautiful thing. We had an ambitious project on a tight two day deadline. With a brand new Pinch team who had all of five minutes to hear the product idea, it was time to plan. We took the team through the refined Pinch planning process and rapidly burnt down feature sets over the next day.

Day two was a bit more challenging. Things were running behind with some of the post review features, and we ended up a few team members short due to other obligations. We knew we had to drop some work, fast. We reacted quickly and re-challenged the MVP. Everyone agreed that delivering the project without the packaging and hosting features would still prove valuable to facilitators, yet we would want to add them prior to a real world market launch. With scope intentionally cut by committee, all remaining features delivered strong.

Review was demonstrated live at Hack Nashville 4. The MVP demonstration consisted of: accessing a marketing site, sign-up, (demo) payment, authorizing your Google+ account, spawning Hangout(s), loading the Review software into the Hangout, using the Facilitation controls, using the Attendee controls, and speaking to how to use everything to Facilitate product reviews in a great new way.

The Review founders have communicated their intentions to polish up the product and deliver the cut features for a stronger market entry. Launch date TBD.

Review Team / Founders:
Luke Stokes · Steve Brownlee · Jesse Gray · Cale Mooth · Jared Bunting · Brendan Wovchko · Charles Penner

Feedback

- Jared Bunting

- Luke Stokes

- Marcus Whitney

- Brian Akers

About: Authors

Jesse Gray

Jesse Gray

Scrum Coach at HUGE I/O

Lead Author of Pinch

Jesse Gray leads product teams through empowerment and service. Armed with an Agile mind and a little bravery, he is able to serve teams as an effective Scrum Coach and Scrum Master.

Gray succeeds at being an agent of positive change within the organizations he serves. Impeded and distracted builders quickly transform into high performing teams under his mentorship and bulwark. He is quick to implement healthy ways for the business and the builders to coexist and hold each other accountable, all while quality product flows out the door.

In his time leading technology teams, Gray has delivered strongly with startups, established businesses, and government agencies including: Emma Inc., Avon, Maritz, L-1 Identity Solutions / MorphoTrust USA, TSA, FBI, and several State Agencies.

Gray organizes and empowers the high performing teams that in turn deliver high performing products.

Connect with Jesse

Brendan Wovchko

Brendan Wovchko

Managing Director of HUGE I/O

Co-Author of Pinch

As founding CTO of two acquired start-ups at the intersection of entertainment and technology, Wovchko is an accomplished product development executive specializing in the radical transformation of software development teams. He has been recognized by Entrepreneur Magazine as a "social networking expert".

In addition to his own ventures he has advised start-ups in technical product development including Avon, Maritz, Huffington Post, Thrillist, Big Machine Records, Emma, HealthTeacher, and Anschutz Film Group. He is a mentor to JumpStart Foundry, a seed-stage microfund, managed by a group of 20 individuals with extensive experience as entrepreneurs, software developers, or early-stage investors.

Wovchko serves as Managing Director of HUGE I/O, a firm specializing in embedding Virtual CTO's within organizations seeking to implement an Agile/Lean operational methodology.

Known for his Agile/Lean management style, Wovchko supports some of Nashville's best-known firms as a Virtual CTO.

Connect with Brendan