FAC MVP process

[iteles]

@sofer Offered to start putting this together in the April 22nd Curriculum Development meeting (will also add a link to this in the FAC5 gitbook)

[sofer]

@iteles Have added some notes on process (although not yet added to README).

https://github.com/foundersandcoders/playbook/blob/master/projects.md

[sofer]

@iteles feedback requested on updated copy. https://github.com/foundersandcoders/playbook/blob/mvps/mvps.md

[sofer]

@Jasonspd @Neats29 @gregaubs @MIJOTHY @amilvasishtha @oluoluoxenfree @adamkowalczyk @perborgen @rorysedgwick @sarahabimay @beechware Please have a read of https://github.com/foundersandcoders/playbook/blob/mvps/mvps.md and leave comments here. This is intended for the FAC5 cohort, but as most of you are still working on MVPs, you may wish to adopt and contribute to these guidelines yourselves. Your feedback is very much appreciated.

[adamkowalczyk]

Some thoughts.

Client Expectations

This was a particular problem working on Fikay, but also reared it's head a bit with Mummy Workouts. I feel there are two attendant issues.

1) Setting Expectations

Both MVPs I've worked on, the client has come in expecting (or at least hoping for) a pretty finished product, and a lot of features. I suspect that they should have known better (but, see below). However it would be good if the clients we're given a clear understanding of what to expect, in writing, before we engage with them. I'm aware that some of this is addresed in the MVP FAQ, but we still ran into issues. I think I'm suggesting something a little stronger, like a mini contract or deliverable outline.

Suggestions:

• That the MVP is provided 'as is', and is unlikely to be finished product (depending on the required complexity).
• The the MVP will be delivered as 'code only', not as a live service. It may be on heroku for a time for them to review/show, if required.
  • This is an issue, as the clients are likely to lack the knowledge to install the service themselves.
• That they will be asked to use pivotal-tracker and engage with the development process.
  • We had one very negative reaction to using PT.

2) Communicating Expectations

This is a big issue. We didn't really know how our clients had been prepared, and what they had been told to expect. I'm sure that a lot of things I'm talking about here had in fact been addressed, and the problem was the clients lack of attention rather than a deficiency in preparation.

However, unless a team know for sure what the client has been told, it's very easy to end up on the back foot, promising to deliver things that are far too ambitious and feeling unable to push back.

I suggest that a written MVP specification, as discussed above, (shared with the team as well as the client) would help a novice team know where they stand.

Background Information

There are some things that it would be very helpful for a team to know prior to the client coming in on the first day. For example, with both Fikay and Mummy Workouts, the client came in with an existing Wordpress site and hoped/expected that we could build the MVP into it, and this was a bit a surprise and a stumbling block. There were also issues around us expecting to be using TokBox, but the client arriving with something else in mind on the first day. I don't really have an exhaustive list of information to request in mind, but among other things the client could be asked:

• Do you have an existing web-site/service?
• If so:
  • What's the URL?
  • What stack does it use?
  • do you want the MVP to be integrated into it, or connected to it somehow?
• Do you have a database of any kind ( e.g. customer records) that you want the MVP to interact with?
• Do you have any service providers in mind to provide functionality for the MVP?
  • Are you satisfied that these services fit your needs?
  • If not, the team might need to do some research in advance
• Do you have any design assets (e.g. wireframes, sketches, images, logos, fonts) to provide to the team in advance?
• What is the intended purpose of the MVP?
  • e.g. Show to investors, alpha test on a sample audience, launch live to the world fully featured in less than 2 months time.
• Which features of the MVP are priorities? Which features can take a back seat?
  • Understand that some features will likely need to take a back seat..

Of course, teams could ask the client these things themselves, but it's worth remembering that I only have an idea about what to ask after my MVP experiences. The new cohort will need guidance, or some question asking on their behalf.

Payment

Just a thought, but even though we're as junior as junior can be, I think £500 is a steal for a team of <=5 for two weeks. I suggest that the 'only pay if satisfied' guarantee be rescinded (unless it's felt that it's absolutely necessary to attract clients). My concern is that the guarantee might help attract particularly flaky/unfunded clients on a 'nothing to loose' basis. Clients should expect to pay. If a project is a disaster, F&C always has the option of waiving the fee.

[sofer]

@adamkowalczyk this is very helpful.

[sofer]

Feedback received so far: "In my experience 3 has been the optimum but 2 and 4 are great too depending on the people." We should have "2 or 3 max" 2-week rounds before dropping to one week. More support during MVPs would have been very helpful.

Please keep your comments coming.

[sofer]

The client view of the suggestion about payment from @adamkowalczyk : "so long that there was a mechanism where I could get a part/full refund if the final product wasn't to spec (or perhaps pay only a % upfront). My biggest concern at the moment is timing. If you could give me an earlier finish date with some certainty, I'd be much more inclined to pay upfront."

[adamkowalczyk]

Just to note, I wasn't necessarily advocating payment upfront, just not making a 'no need to pay if you're not fully satisfied' promise.

On 6 May 2015 at 15:18, D Sofer notifications@github.com wrote:

The client view of the suggestion about payment from @adamkowalczyk https://github.com/adamkowalczyk : "so long that there was a mechanism where I could get a part/full refund if the final product wasn't to spec (or perhaps pay only a % upfront). My biggest concern at the moment is timing. If you could give me an earlier finish date with some certainty, I'd be much more inclined to pay upfront."

— Reply to this email directly or view it on GitHub https://github.com/foundersandcoders/playbook/issues/4#issuecomment-99484275 .

[sofer]

@adamkowalczyk I am advocating payment up front :-)

[adamkowalczyk]

:+1:!

On 6 May 2015 at 16:03, D Sofer notifications@github.com wrote:

@adamkowalczyk https://github.com/adamkowalczyk I am advocating payment up front :-)

— Reply to this email directly or view it on GitHub https://github.com/foundersandcoders/playbook/issues/4#issuecomment-99504581 .

[oluoluoxenfree]

When are students taught how to wireframe and produce invoices?

[iteles]

@oluoluoxenfree Wireframing is day 1, invoicing is not a thing.

[sofer]

I am closing this now as we have an agreed process (at least for now!). Thank you for everyone's input.