Is it too much to ask interested job seekers to use our product first?
5 comments
I think people should research a company before working for them, and I'd definitely download the app and act like a consumer to get a feel for how the product works. I wouldn't set up a fake vendor however simply because that seems disruptive to the app's ecosystem and is likely researching a little too deep into what appears to be a basic shopping app.
Honestly if I emailed about a job and they wanted me to set up a "vendor" account, I'd just assume the job was fictional and this was a roundabout way of advertising their app.
> For the fairness of the discussion, the app itself is solid with decent UI and UX.
That's a strange line. Typically when expressions like "for the fairness of the discussion" are used you say something self-reflective to ward off "obvious" criticisms. The way you're using it here is like "For the fairness of the discussion, I am awesome!" Just a really strange turn of phase, not sure what you're trying to convey with that.
> So did I ask too much? Or I expect too much?
You expect them to care as much as you do. That won't happen. They have no vested interest in it.
Bring them in, talk through the app, find out their thoughts/ideas/problems and see who you like.
Honestly if I emailed about a job and they wanted me to set up a "vendor" account, I'd just assume the job was fictional and this was a roundabout way of advertising their app.
> For the fairness of the discussion, the app itself is solid with decent UI and UX.
That's a strange line. Typically when expressions like "for the fairness of the discussion" are used you say something self-reflective to ward off "obvious" criticisms. The way you're using it here is like "For the fairness of the discussion, I am awesome!" Just a really strange turn of phase, not sure what you're trying to convey with that.
> So did I ask too much? Or I expect too much?
You expect them to care as much as you do. That won't happen. They have no vested interest in it.
Bring them in, talk through the app, find out their thoughts/ideas/problems and see who you like.
It is better when the programmer can be a user of the software. But it is not always necessary, and may also be counter productive.
One pitfall can be when the programmer is motivated to "improve" the software indiscriminately. Being a user, he's of course in the best place to debug and add the features he uses and wants. But from the corporation and marketting point of view, it's not always the best: the product owner may want to prioritize the work done on the software on other criteria than a user/programmer might have. In those situation it may be better if the programmer is less of a user of the software and just implements the requirements, from a technical point of view.
The software development requires knowledge and skills that may be quite different from the knowledge and skills required of the user of a program, and when the application domain is quite exotic (from the point of view of the programmer), it may be understood that while the programmer can write the code implementing the specifications, he may not have the ability to run (effectively) the program. Again, it may be unrealistic to require extensive domain knowledge from everybody from the team. This is something that the product owner and functional analyst provide. The programmers will provide the computer science and engineering knowledge.
As a program developer, I don't know anything about farming, but the most general notion. I made a bean seed germinate as a pupil, and a dug a garden plot once, and that's about all I know about this business. But I know about databases, client/server applications, and user interface development. As long as you can give me some specifications for a "marketplace system for farmers", I can write the software.
Of course, I'd agree that at least the person interested should try out the software if it's possible. But when I do that, I realize that:
0- I mostly use it blindly, without understanding much of what's happening,
1- I can only provide suggestions about superficial elements,
2- moreover, my suggestions are strongly influenced by my biases, as a programmer (eg. I tend to have a preference for textual CLI, emacs-like user interfaces and programmable systems).
You definitely want a real user, a domain expert, to use your software, rather than programmers.
Of course, unless the software is a developer tool (but even then, some prefer IDE, some prefer unix environments, some prefer emacs).
One pitfall can be when the programmer is motivated to "improve" the software indiscriminately. Being a user, he's of course in the best place to debug and add the features he uses and wants. But from the corporation and marketting point of view, it's not always the best: the product owner may want to prioritize the work done on the software on other criteria than a user/programmer might have. In those situation it may be better if the programmer is less of a user of the software and just implements the requirements, from a technical point of view.
The software development requires knowledge and skills that may be quite different from the knowledge and skills required of the user of a program, and when the application domain is quite exotic (from the point of view of the programmer), it may be understood that while the programmer can write the code implementing the specifications, he may not have the ability to run (effectively) the program. Again, it may be unrealistic to require extensive domain knowledge from everybody from the team. This is something that the product owner and functional analyst provide. The programmers will provide the computer science and engineering knowledge.
As a program developer, I don't know anything about farming, but the most general notion. I made a bean seed germinate as a pupil, and a dug a garden plot once, and that's about all I know about this business. But I know about databases, client/server applications, and user interface development. As long as you can give me some specifications for a "marketplace system for farmers", I can write the software.
Of course, I'd agree that at least the person interested should try out the software if it's possible. But when I do that, I realize that:
0- I mostly use it blindly, without understanding much of what's happening,
1- I can only provide suggestions about superficial elements,
2- moreover, my suggestions are strongly influenced by my biases, as a programmer (eg. I tend to have a preference for textual CLI, emacs-like user interfaces and programmable systems).
You definitely want a real user, a domain expert, to use your software, rather than programmers.
Of course, unless the software is a developer tool (but even then, some prefer IDE, some prefer unix environments, some prefer emacs).
Thanks. I do appreciate what you have put together.
I am a little curious what motivate a person to send an email to me and say he is interested in the co-founder role. Idea alone?
No and yes.
It's not asking too much that someone familiarize themself with your app.
It is asking a bit much that they care about it in the same way you do, though. As a dev, their job is to ensure it functions the way you want it to. As sales and marketing, their job is to create and sell the idea that your app will have value.
Anything beyond that is optional and goes beyond what you can reasonably expect to hire someone for. If you find someone willing to go above and beyond, that's great. Encourage it by sharing your idea and enthusiasm for it.
But don't expect it right off the bat.
I've been willing to take jobs because the tech stack was interesting, but the overall market was something I didn't really care about at all (sports).
It's not asking too much that someone familiarize themself with your app.
It is asking a bit much that they care about it in the same way you do, though. As a dev, their job is to ensure it functions the way you want it to. As sales and marketing, their job is to create and sell the idea that your app will have value.
Anything beyond that is optional and goes beyond what you can reasonably expect to hire someone for. If you find someone willing to go above and beyond, that's great. Encourage it by sharing your idea and enthusiasm for it.
But don't expect it right off the bat.
I've been willing to take jobs because the tech stack was interesting, but the overall market was something I didn't really care about at all (sports).
what if you have been invited to be a co-founder role? I guess I shouldn't expect developers to have the same passion as I do. I hope the interested co-founder candidate should have some passion about the domain. I feel that it is very difficult for a co-founder to stick with the project if he/she don't agree this project is solving some problem he/she cares about.
Depends on the type of co-founder, I suppose.
Having been more-or-less a technical co-founder (or maybe a co-co-founder) I found the technical issues fascinating, but ultimately, I wasn't sure if the business model was a good idea or not. So, I stuck to technical issues and kept my mouth shut (or tried to) about anything outside my area.
The one time I had to say something was when the Social Media person suggested what sounded like astroturfing. I was against it then and I will always be against it.
Having been more-or-less a technical co-founder (or maybe a co-co-founder) I found the technical issues fascinating, but ultimately, I wasn't sure if the business model was a good idea or not. So, I stuck to technical issues and kept my mouth shut (or tried to) about anything outside my area.
The one time I had to say something was when the Social Media person suggested what sounded like astroturfing. I was against it then and I will always be against it.
Yes, I think that's asking too much in this case. How many farmers do you know that are actively pursuing a programming job?
I don't quite get it. The Co-founder role is for marketing and sales.
I overlooked this detail and assumed based on your pot title that you were looking for potential programmer hires to use your product. My opinion still stands; farming is a relatively rare occupation in the software industry, marketing or otherwise.
It's one thing to make sure a potential cofound understands your pain point and market, it's another thing to ask the candidate to be part of the market.
It's one thing to make sure a potential cofound understands your pain point and market, it's another thing to ask the candidate to be part of the market.
I remember you posting about your start-up back in August. How have things progressed since then?
Thanks for remembering me. It goes pretty well for product development. We have 6000 market vendors information now. We also build some tool for market organizers.
I have also worked with a few developers who wanted to be part of this project. And I got the feeling that they don't like to play this app either.
I am actually disappointed.
For the fairness of the discussion, the app itself is solid with decent UI and UX.
So did I ask too much? Or I expect too much?