As a non-coding founder, how do you begin with product management with in-house developers in order to have complete control over the product?

Current state: I have prepared the design & features document. And developers will be joining team soon. Can you help me as how can I always keep a check on development and also have complete control over it?

P.S: I did OOP till 10 years back and I also have fair bit of idea of Python. Currently, I am developing a payment product for the lower income group in India and I aim to achieve a transaction time of less than 10s in days (years) to come.

9 Likes

I see two different threads here. One is regarding checking on development progress, the other is on product management. I’ll address them individually.

Product Management is a beefy topic, but in general, you should understand that a “design and features” document is outdated as soon as you create it. You should be optimizing your product backlog for short feedback cycles and delivering iterative value to the user. The longer between releases and feedback gathering, the more risk you’re building into your product.

For tracking developer progress, make sure you have your backlog in a state where individual user stories are “complete” and prioritized, and make sure everything is tracked in a tool like Trello, Jira, or Pivotal Tracker (disclosure: I work in the consulting arm of Pivotal Labs, and we use Tracker). If you build in a culture of frequent communication and updating of your backlog, measuring progress should not be an issue.

9 Likes

Thank you. Yes shipping is a priority and hence I have written on my desk the longer it takes to ship, higher is the possibility that it will not get shipped.

I am using Trello as a tracker tool and my conversation with the remote team is weekly. They are CS students in Univ of Waterloo (known them before they went to college).

Requirements have changed thrice in a month because we found efficient ways of doing the task during the pilot. Hence, the progress is slow. I don’t mind that because we want a min product that serves max adopters.

How is updating a backlog different than a tracker/ requirements document?

8 Likes

Check out the book The Lean Product Playbook by Dan Olsen, it is a great starting point and a quick read!

8 Likes

Make sure you pay your developer and that they are doing ‘work for hire’. Otherwise, you’ll not own the ‘product’, they will.

7 Likes

I’ve never respected anything that comes for free and believe in it while hiring even an intern. I have always been paid and I make sure that payment is defacto.

6 Likes

I use a site called Bubble to quickly prototype my apps into a full working versions before spending money on “real” development. You can have your team of coders remake it later with ‘real’ code to become more flexible… But this way you can have the product up and running VERY quickly to get proof of concept before spending a ton on development…

7 Likes

Bubble worked really good for me. It’s easy and fun. Thank you so much for the reference.

6 Likes

I’m a similarly non-coding founder. We’re using a combination of trello and storiesonboard for product/project management, and it’s fantastic.

In short, make a series of lists on trello: Inbox, To Do, Doing, and Done (we use more lists that are broken up to a higher resolution, do what suits you best).

Then make a project in storiesonboard. Set up all of the feature and technical cards as normal. Connect the trello and storiesonboard accounts, and push the cards from storiesonboard to trello in the order in which they’re built. This way you can prioritize what is built first, and see everyone’s progress in real time.

I’ll leave learning how to use trello and storiesonboard for someone else to explain. Or you can just figure it out yourself, it isn’t that hard!

5 Likes

@Marco, Thank you. I am using Trello for the same reason. I don’t mind if someone can explain using storiesonboard & Trello further deeper.

5 Likes

Because I’m so generous, I made a short video showing how to create and link a storiesonboard project and trello board. Just make a storiesonboard account and you can link them up easily. Have fun!

5 Likes

I’m a product manager, and have taken the following approach with my own side project recently:

  • Before ever involving a developer, I built out almost a full requirements document in Axure. This included actual requirements and high fidelity comps.
  • I found a developer that I wanted to work with, and we decided to use agile and break it apart into bite sized pieces, aka sprints.
  • I exported everything from Axure, and we created a Scrum board in Trello, with several lists. Some of the lists are backlog, next sprint, current sprint, ready for test, done, etc (and as we finish a sprint completely, we create a new list for it, then date it and number the sprint). I have several lists that are comparable to “Epics” and then within each list there are cards that break it apart screen by screen. Then within those cards, there are checklists that spec everything out. My developer drags cards over from each of those lists into the “current sprint” - he just drags over what he estimates he can finish in 1 week.
  • As issues come up, my developer can just flag items with labels, comment, etc and I can chime in with feedback. I can see the progress he makes as he drags cards over into different lists (e.g. as he moves cards from current sprint over to ready for test). At the end of each week he sends a new build for me to test. We do most of our day-to-day communication in Slack.

We’re about 3 weeks into dev and I’m very pleased with the overall process. There is tons of visibility. I have a background in startups, and have been back in the corporate world for the past 3 years, so this is a breath of fresh air. It’s been super efficient.

Let me know if you have any other questions! I’d be happy to give additional details if it’ll help.

4 Likes

Im still a senior in college for CS, but I can help out a little. One of the biggest problems there is you have to keep it an AGILE environment, and make the Software Requirements correctly. Make a ton of user stories of someone who is using your code. For example: user logs in, comments on video, likes the video, and later receives a notification that someone replied to him.

Make a ton of those, and a ton of Pictures representing what each screen will look like, as well as the logic for each use case.

As for keeping them in an AGILE mindset, have a weekly or bi-weekly meeting on what they did, and have them show that their features are working. Also get them in the habit of asking you questions. In fact, tell them the more you talk to them about things they aren’t sure of in the product the better, and the more they are fulfilling their job.

I think part of the reason that the manager loses control over the product is because either it is easier to do one way, or it is more logical. In java the GUI creator kind of sucks for example, and certain GUI’s are hard to do, or the developer might not want or know how to do a very specific odd thing.

The more pictures of how the product works the better though honestly because it will not only help you flesh out your understanding of it and what you want, but also programmers inherently hate trying to be creative, and its always easier and less risky to program something that is shown on a picture, sketch or what’s on a whiteboard. If you have an artistic deficiency, I’m sure some artists would love 5-20 bucks to sketch a nicer looking arrangement of boxes.

3 Likes

Many aspects of agile development can be helpful and useful but many people take it too far. Make sure the agile dogma doesn’t kill the momentum of your developers.

2 Likes

Yes!

I’m 40…been writing the codes professionally for about 20 years now, and come from the cowboy coding era before things were so specialized.

One of my actual strengths is to understand how design and coding fit together in a unique way, since I have a design background, and years of practical experience.

While I love the agile process to help identify tasks, it only goes so far as you break down the tasks.

If your technical manager just tends to leave big epics not broken down into their actual tasks, it can have a weird effect on tracking velocity and keeping on track.

But then there are tasks that take longer to write up, then just asking.

Right now we’re in the spot where we over-document, and I routinely get tasks that probably take 5 minutes to write up, where it’s seriously like changing a hex color in a sass include or something trivial…

Since I’m the oldest, and only remote employee, it’s kind of hard for me to really have a say in how that process is run, and it’s just easier for me to adapt to whatever they come up with since I’m a little bit more used to thinking on my feet than some of the juniors, but they like to do weird things to cut Fridays short, and I’ve been suggesting “hey why don’t you design people, and you programming people just get together and talk about little tweaks for an hour or so”

Like whenever I’m out there and wrapping up a new feature, I make it a point to pull the designer aside and walk through what I’ve built with them, explain things in a way that they could design it more effectively (never about aesthetic, usually just little details at this point), and allow them to make a few adjustments so they feel like we’re working together on the product.

That’s like the most difficult thing for them to do though, they’d rather have a 7 person team take a happiness survey than actually just talk shop and whiteboard because it’s fun.

1 Like

Thank you. We have already gone through two iterations of requirements and stopped at third because it made sense in shipping a product to understand our users than perfecting a plan.

Yes, I agree pictures make a lot of sense hence we have come up with wireframes. It decides the flow of the app and the developers can visualise the output before shipping it.

Even before developers have come on board, I am having weekly meetings with them to bring them at par with the way our customers are behaving in the pilot program.

I just came back to check this post. Dan Olsen’s book The Product Playbook has been really helpful. One thing that has been consistent throughout the development is the user stories. It has really helped but we have not been recording it on any tracker. We’ve been managing it because we are a small team but we have begun discussions to take stories to Trello.

On the other side, we not only have our product with early users now but also paid customers! Woo hoo. Thank you so much.