Suggestions: Stakeholder buy-in to MVP
Inevitably, a SaaS product grows, there's hundreds of little features that stakeholders would like to have implemented, and it should have been done yesterday.
I always start a project off, by making an interactive mockup of the main functionality, I then explain that this is a demo, and not the final product.
Everyone agrees.
I then explain that we can add any amount of features, and pretty much do anything.
Everyone agrees.
I show them the mockups, and everything goes to hell.
Where's this!? Where's that!? How do you expect me to pay for this? There's nothing here?
I've had a few opportunities over the past 3 years, to create, from scratch, SaaS products. The first few times that the above happened I attributed it to the client/stakeholder not really being invested in the idea.
But it happened again yesterday, and well, eventually you have to accept that maybe you are the source of the problem.
I would like to ask this awesome community for some ideas/suggestions/processes on how to sell this idea of MVP, and keep expectations in check?
Thanks to everyone here!
Ciao
Huge topic!
As starting point, these Saas products are something you believe in it, is part of your vision, you are one of the customer? Without this initial "commitment", you rely to someone else to understand exactly all these little things, right ?
About your actual question I don't think you are source of the problem, maybe something you do ? Do you listen what customer said before doing the mockup ? Or you are providing a solution without in deep knowledge for the problem ?
But in any case.. you can always change the mockup, evolve it, on little and big things, right ? You are on mockup phase, so customer could be "educated" that anything could be changed, and mockups are one of the tool to clarify and have a common "idea" for the system.
I think you are right, a little more time spent writing down requirements and organising them can't hurt :)
Do you have a standard way you would approach this? I'm thing a trello board, each column a category of functionality?
I want to "stress" you (lol) on think about your approach, if you want to write down here how do you prepared on this meeting, what you have done, etc..
For "formal" requirements definition there are uses cases: https://en.wikipedia.org/wiki/Use_case but for me "most useful" diagram is https://en.wikipedia.org/wiki/Sequence_diagram because shows who does what and when, critical to understand before do any mockup
The reason I'm asking for community feedback is that in my experience with use cases, clients (well those who don't have a dedicated project manager) tend to not understand or care about use cases.
These are great, and instrumental in development, but they mean nothing to clients (even though they should).
I've had cases where you lay out for example, "The initial dashboard will consist of only 1 chart, showing the daily visiter count for the past week". And the client signs off, and comes back with "where are the rest of the graphs, we can't launch without the rest of the graphs"
Well.. if they are honest you should always remember that they decided for one chart, not for two and politely say something like "This is my understanding on what we have decided, we can always improve, let's start from this starting point our discussion. There is something else you think should be added ?" and after the discussion highlight main points (must have) and desired (could have)
I think you're right, lack of standing up for myself might be a big contributing factor in all this.
If I'm interpreting correctly, your initial interactive mockup is Version 100, and you're using it to sell a vision. If that's the case, I highly recommend avoiding that approach. People are really good at noticing when something is missing if you've already shown it to them.
Instead, if you can focus entirely on the value you plan to deliver, rather than HOW you plan on delivering, you're able to change the conversation. I'd also say that thinking in terms of a big interactive mockup kinda defeats the purpose of an MVP. The point of the MVP is not to outline the first version of some big thing, but rather to test your assumptions about a solution to a problem as quickly as possible. If you're putting together comprehensive mockups, you're making a TON of unvalidated assumptions.
Thanks! This is great feedback.
I guess I'm stuck on "step 2" after I have the initial requirements, what should I do to move the conversation forward? In my (perhaps limited) experience, a client usually wants to see something after this conversation, should it maybe, be wireframes?
If you have an article/book/recommendation you could point me to?
Is this client work? Or a product you're building and own and are trying to get customers for?
A bit of both really, let me explain.
I have 2 projects that I'm trying to launch. I switch between them while waiting for feedback on one or the other, and while unfinished dreams don't pay the bills, I take on client work (usually only takes a day or two), which just restarts the whole process in a smaller cycle :P
In both cases there are partners, they are already established in their respective industries, and have many clients.
Both projects required substantial upfront research time on my part:
Project 1) Requires complete offline capabilities and data versioning
Project 2) This one's heavily graphics based, so I needed to look into viable options for graphics design & export & pixel perfect rendering of those designs in a browser
After the few months of research, and the concepts proven, I really want to start getting it out there, but they are dragging on because of the reasons described above, they are essentially unwilling to start on-boarding customers or showcase work, until the systems are "complete".
I have reached the point where I want to put my foot down and we either launch with what we have or part ways, but that led me to try at least one last time.