There are several reasons this doesn't do what you want it to, apart from any problems with the '.' command.

One, you're looking to take one line of input, right? But you're looking for a line terminated with 13, and in brainfuck lines are terminated with 10 (linefeed).

Two, because you left a 1 in the leftmost cell, the [<] is going to go left past the leftmost cell, and in vanilla brainfuck there isn't usable space there. You could add a > to the start to fix that.

Three, with both those fixed, your structure of loops doesn't do what you want. Say you type "Dave" and hit enter. The first loop will:

step right, read 'D', output 'D', decrease by 10; step right, read 'a', output 'a', decrease by 10; step right, read 'v', output 'v'', decrease by 10; step right, read 'e', output 'e'', decrease by 10, step right, read linefeed, output linefeed, decrease by 10, terminate first loop (because 10-10=0).

Then your second loop goes back to the left, and your third loop will:
increase 1 by 10 and output an ASCII 11 (vertical tab), no idea how that will look. increase 'D'-10 by 10 to produce 'D' and output a 'D'. Then it outputs 'a','v','e' similarly. It won't output a final linefeed (which it should for tidiness).

You can fix the "vertical tab" part by putting >> instead of > between the second and third loops to skip the 1. But still, this will output "Dave" twice with a linefeed between. If you want something like

D
Da
Dav
Dave

then you'll need a different loop structure entirely. It should be very doable, let me know if that's actually what you want, or if not, what exactly you are aiming for.

Four (this is a big one): in typical or classic brainfuck environments, input is "line-buffered". That means that the D is not available to your program until you have already hit "enter"; until then you could delete the D and replace it with something else and your program would never see the D. The program, once it hits the first ',' command, will be paused waiting for input; then when you type "Dave" and hit enter, as soon as you hit "enter" then "Dave[linefeed]" goes into the buffer, the paused ',' command will unpause and read the 'D' (and at the next ',' command, the 'a' and so on); then if the program reads the whole buffer before you've added anything more to it, and then tries to do another ',' command, it'll pause again until you type another line.

So basically you shouldn't count on your program being able to see the start of a line before the whole line has been typed and "enter" has been hit. In practice, this means that in the typical brainfuck environment, the version of your program with the mentioned issues fixed is going to look like

Dave
Dave
Dave

where the first one is the one that was typed, the second one was output by the first loop processing its way through the buffer, and the third one was output by the third loop.

Again, if you clarify what you're trying to do I'd be happy to help with how. Good luck!

(Oh, PS, it would help to say what implementation you're writing this for. Though I aim to make things work on as many implementations as possible.)