Enterprise SaaS question: Pilot customer

We are building a MVP for enterprise SaaS, focused on Proposal automation. Questions: 1. Looking at our customer`s Decision Making Unit, users want features for time and effort savings via collaboration, while decision makers want to focus on features for risk of proposals. There are 2 different sets of features that address these 2 aspects. For MVP, what is more critical? Easy to build user features (but with caveat of not being paid) or time-consuming to build decision-makers focused features, with more likelihood of getting $.

2. When and how to raise $ for Beta product development, as we are building clickable wireframes now and about to lock-in the first Pilot customer in next 30 days. We do not have any revenue today.

Regards,

A.

5 points | by arvindpurdue123 1248 days ago

1 comments

  • Jugurtha 1247 days ago
    Have you spent time with all of them around the table and thinking about their needs and problems, not features?

    In my experience, if you're not careful during the early product design phase, people will spit out features or their solution/implementation. One has to snap out of it and figure out the reasons of these. They want a button, you must ask why and figure out the job to be done.

    Second, from all the 'features' which you figured out the problems for, what is common between the two (users and decision makers)? Is there a core/common set you can extract ?

    Third: you can sort of layer specific features of one and the other on top of the core, if there is a core, and propose two products. Depending the budget.

    Lastly, it may be frustrating, but ultimately: who is paying you? If you're doing consulting, you may provide input but the one who pays you have the last word. Get your input and their explicit decision to go a certain route in writing, and do what they ask of you.

    I wrote a tiny bit about this here https://mobile.twitter.com/jugurthahadjar/status/13106682933...

    Again, spend time on problems and unearthing the underlying problems that the features they propose are solutions/implementations to. Don't let the product driven by feature proposition.

    • arvindpurdue123 1247 days ago
      Thank you for that insight. Your product looks interesting. Still doing early access?
      • Jugurtha 1246 days ago
        You're welcome. We also are careful to include problem and rationale in our own product internally. When one of us wants a feature or one of our data scientists asks for a feature "I want a button to click and do X", we ask "what are you trying to accomplish?" and focus on the job to be done. People naturally go for solutions/implementations and we can be completely oblivious that the solutions we propose are a result of our knowledge or lack of knowledge.

        Here's our issue template for features to lower the barrier to write good issues:

          <!--These are comments and will not be rendered. Please click Preview to check.-->
          
          ### Description
          ----------------
          
          <!--Describe the problem we'll solve. What, where, when, who, why, and how.-->
          
          
          ### Target
          ----------
          <!--Who's the target audience? Who'll enjoy this the most or suffering from
              lacking this feature the most? Is this a problem you have? Have you talked
              with other people who have this problem? Is it something that would just be cool?
              Is it a seed for an idea that can be cool?
          -->
          
          
          
          ### Instances
          -------------
          
          <!--If the problem has happened multiple times, can you describe them-->
          
          
          ### Proposal
          ------------
          
          <!--What is the plan to solve this problem? Can we guess a solution or have a hunch?
              Do we have a list of steps? It's okay if they are a bit vague for now. We'll clarify
              by debating them and adding context to them, reading more about the subject. It's 
              essential to understand that this document serves to capture thoughts and externalize
              thought processes so we can all tackle the problem more effectively.
          -->
          
          
          ### Resources
          -------------
          
          <!--Do you recommend any reading to do about this? Maybe a video to watch for something similar?
              Maybe a blog post or documentation pages or just a snippet? An image, mock-ups, etc...
          -->
          
          
          /label ~feature
          /cc @XX @XY @XZ
        
        
        >Your product looks interesting. Still doing early access?

        Yes. Here's an invite link if you'd like to try it: https://iko.ai/invite/terXtLhraD1hPx2Gw16EgUAHMy98mWqq2vlm9M...